Azimuth Dashboard Security Posture
Version 1.1 — 20 August 2026 Scope: Product-level (application) security of the Azimuth dashboard and its embedded agent — what protects a customer's data and accounts inside the product. Platform/cloud controls are covered in Azimuth Cloud Security Posture; data lifecycle and gates are detailed in Azimuth Data Governance.
Change log: v1.1 (20 August 2026) — customer-facing revision; controls stated in present tense.
1. Security model in one paragraph
The dashboard is the control plane; the agent is the worker. Every consequential action — importing knowledge, generating content, approving, publishing, spending — passes through a gate that is enforced by the dashboard, not by agent goodwill. The agent cannot approve its own work, cannot publish unapproved work, cannot see restricted data it doesn't need, and cannot receive instructions from the content it reads. Everything it does is written to an append-only audit log.
2. The gates
Each gate is a hard control: the action is impossible without passing it, and passage is logged.
| # | Gate | What it blocks |
|---|---|---|
| G1 | Authentication & admin allowlist | Anonymous access; non-admin access to admin surfaces — administrative access is restricted to named accounts and re-checked at the data layer |
| G2 | Guardrail scan at ingest | Restricted content (program names, ITAR/DFARS-adjacent data, non-public financials, personal data) entering agent context unlabeled; embedded prompt-injection text acted on as instructions |
| G3 | Compliance flag gate | A flagged draft being approved — the flag must be resolved by inline edit or explicit acknowledge first; flags name the exact span, the rule, and the minimum fix |
| G4 | Human approval gate | Any publish or schedule without a named human approving the final version; approval creates an append-only ApprovalRecord (artifact version, approver, decision, timestamp) |
| G5 | Audit log | Silent action of any kind — every agent run logs model version, prompt version, sources, outputs, flags, approvals, and external post IDs; edits create versions, never overwrites |
| G6 | Direct-to-provider API boundary | Customer content transiting third-party middleware — generation calls go server-side, straight to the model provider under no-training terms; provider keys never reach the browser |
| G7 | Connector authority | The agent acting on a platform account without a live, scoped, allowlisted connector; capability is checked against the connector's configuration before any channel is used |
| G8 | Autonomy ceiling (L0–L4) | Irreversible or high-impact actions (unapproved spend, legal statements, crisis comms, account changes) — prohibited by default regardless of prompt |
3. Authentication & session security
- Login is required for all non-public routes; session tokens are handled by the auth layer, not hand-rolled.
- Admin allowlist: administrative capabilities are gated to explicitly named accounts, checked at login and re-checked at the data-access layer, so a spoofed toggle gets nothing.
- Role-based access (org member vs approver vs admin), with approver identity captured in every ApprovalRecord.
4. Agent containment
- Untrusted-content rule: documents, pages, and comments the agent reads are data. Embedded instructions are recorded as security flags, never followed.
- No self-escalation: no agent or sub-agent can grant itself tools, budget, or publishing authority.
- Span-level blocking: the compliance auditor blocks at the level of the offending sentence, so restricted data cannot ride out inside otherwise-clean copy.
5. Secrets & client-side security
- No secrets in the frontend bundle; provider keys and connector tokens are server-side only.
- Demo/prod separation: demo data ships only in demo builds.
6. Trust surfaces
Security is also shown, not just done: the GovernanceBar (app-wide status of gates on the current piece) and the Trust Center (/governance) present live governance state to the customer. Claims shown there follow the honesty rule — stated plainly, never inflated.
7. What an attacker would try, and what stops them
| Attack | Stopped by |
|---|---|
| Prompt injection via uploaded doc or scraped page | G2 ingest scan + untrusted-content rule (flagged, not followed) |
| Exfiltrating restricted data into a public post | G2 classification + G3 span-level compliance block |
| Getting the agent to publish directly | G4 — publish path requires human ApprovalRecord; agent has no route around it |
| Stealing provider keys from the app | G6 — keys server-side only, never in bundle or browser |
| Tampering with history after the fact | G5 — append-only log and versioned artifacts |
| Using demo/admin surfaces as a side door | G1 — admin allowlist re-checked at the data layer |
| Escalating a sub-agent's authority mid-run | G8 — no sub-agent can grant itself tools, budget, or authority |