Security Model
MACAW's security model reduces AI workflow protection to four boundary crossings. Every operation is verified for both intent (policy compliance) and integrity (cryptographic authenticity), using a defense-in-depth architecture where each component verifies independently.
The Security Problem
AI workflows introduce security challenges that traditional access control wasn't designed for:
Traditional Systems
- - Request-response, deterministic
- - Clear boundaries (network, process)
- - Static permissions
- - Human operators
AI Workflows
- - Multi-step, non-deterministic
- - Blurred boundaries (prompts, tools, data)
- - Dynamic context-dependent decisions
- - Autonomous agents acting on behalf of users
Key Insight
Security for AI workflows reduces to protecting boundary crossings. If we can verify intent and integrity at each boundary, we can secure any workflow regardless of complexity.
The Four Boundaries
Every AI workflow crosses four security boundaries. MACAW verifies operations at each crossing:
┌─────────────────────────────────────────────────────────────────┐ │ AI WORKFLOW │ │ │ │ User Input ──▶ [S1: PROMPTS] ──▶ LLM Processing │ │ │ │ │ ▼ │ │ [S2: TOOLS] ──▶ External Systems │ │ │ │ │ ▼ │ │ [S3: DATA] ──▶ Knowledge / Databases │ │ │ │ │ ▼ │ │ [S4: CONTEXT] ──▶ Cross-step state │ │ │ └─────────────────────────────────────────────────────────────────┘ S1 - PROMPTS: What instructions reach the LLM? S2 - TOOLS: What operations can the agent execute? S3 - DATA: What information can be accessed or shared? S4 - CONTEXT: What state persists across workflow steps?
Prompt Boundary
Controls what reaches the LLM. Blocks prompt injection, enforces content policies, prevents instruction override attacks.
Threats: prompt injection, jailbreaks, instruction smuggling
Tool Boundary
Controls what the agent can do. Each tool call is verified against policy. Prevents privilege escalation and unauthorized actions.
Threats: privilege escalation, unauthorized execution, confused deputy
Data Boundary
Controls information flow. Prevents data exfiltration, enforces classification labels, restricts cross-domain sharing.
Threats: data exfiltration, unauthorized disclosure, classification breach
Context Boundary
Controls state between steps. Ensures context carries valid attestations, prevents context poisoning and manipulation.
Threats: context poisoning, state manipulation, workflow hijacking
Intent + Integrity
At each boundary, MACAW verifies two orthogonal properties:
Intent
Does this operation satisfy all applicable policies?
- - Is this user allowed this model?
- - Is this tool permitted for this role?
- - Is this data accessible at this clearance?
- - Policy evaluation at runtime
Integrity
Is this operation cryptographically authentic?
- - Valid signature from known principal?
- - Request unmodified in transit?
- - Context chain cryptographically valid?
- - Cryptographic verification at runtime
The Duality
Both properties are necessary. Neither is sufficient alone.
A request with valid cryptographic signature but policy-violating content fails intent verification. A request satisfying all policies but with an invalid signature fails integrity verification. MACAW enforces both at every boundary crossing.
| Intent | Integrity | Result |
|---|---|---|
| Valid | Valid | Allowed |
| Valid | Invalid | Blocked (spoofing/tampering) |
| Invalid | Valid | Blocked (policy violation) |
| Invalid | Invalid | Blocked (both) |
Two Defense Classes
MACAW employs two complementary defense strategies:
By-Design Elimination
Cryptographic mechanisms make certain attacks impossible, not just detectable.
- XIdentity spoofing — valid signatures require private keys
- XSession replay — nonces and timestamps prevent reuse
- XPolicy substitution — policies are cryptographically bound
- XAudit tampering — logs are append-only with signatures
By-Policy Enforcement
Runtime verification detects and blocks policy violations.
- !Prompt injection — content policy evaluation
- !Privilege escalation — permission checks at tool boundary
- !Data exfiltration — data flow verification
- !Context poisoning — attestation validation
Why Two Classes?
By-design defenses provide absolute guarantees — the attack vector simply doesn't exist. By-policy defenses handle attacks that depend on content or context, which require runtime evaluation. Together, they cover the full threat landscape.
Defense in Depth: True Zero Trust
MACAW implements true zero trust: even intra-agent tool calls go through the verification pipeline. Every tool verifies callers using public keys registered in the Agent Registry (the Trusted Computing Base).
Traditional: MACAW True Zero Trust:
┌─────────────────┐ ┌─────────────────────────────────────┐
│ Gateway │ │ AGENT REGISTRY (TCB) │
│ (single PEP) │ │ Public keys for all tools/agents │
│ │ │ └──────────────────┬──────────────────┘
│ ▼ │ │ verify against
│ ┌───────────┐ │ ┌─────────────────────────────────────┐
│ │ Tool A │ │ │ AI AGENT │
│ │ Tool B │ │ │ ┌─────────┐ ┌─────────┐ │
│ │ Tool C │ │ │ │ Tool A │ ──▶ │ Tool B │ │
│ └───────────┘ │ │ └────┬────┘ └────┬────┘ │
└─────────────────┘ │ │ verified │ verified │
│ ▼ ▼ │
│ Even intra-agent calls verify │
│ against Registry public keys │
└─────────────────────────────────────┘
Gateway bypassed = all exposed Tool compromised = only that tool exposed
Implicit trust within agent No implicit trust, even within same agentTraditional Model
- - Gateway is single point of failure
- - Implicit trust within the agent
- - "Grading your own homework"
- - One compromise exposes everything
MACAW True Zero Trust
- - Every call verified against Registry
- - No implicit trust, even intra-agent
- - Each tool has own keypair in TCB
- - Blast radius limited to single tool
The Agent Registry (TCB)
The Agent Registry in the Control Plane serves as the Trusted Computing Base (TCB). All tools and agents register their public keys here. When Tool A calls Tool B — even within the same agent — Tool B verifies the request signature against Tool A's public key from the Registry. No call is trusted implicitly.
PEP Independence Guarantee
The compromise of any single PEP does not reduce the security guarantees provided by other PEPs. This is enforced through cryptographic isolation — each tool holds its own keypair and performs independent verification against the Registry. There is no shared state that could be exploited.
Agentic Access Control
Traditional access control is binary (allow/deny). AI workflows need graduated controls that govern model selection, token limits, data access, and more.
| Traditional | MACAW Agentic |
|---|---|
| Allow / Deny | Model limits (GPT-3.5 only for juniors) |
| — | Token constraints (500 max per request) |
| — | Data scope (public data only) |
| — | Tool restrictions (read-only access) |
| — | Time-based access (business hours only) |
| — | Workflow governance (multi-step controls) |
Policy Inheritance
Policies cascade from company to user. At each level, the most restrictive constraint wins. Child policies can only restrict, never expand.
Company: "FinTech Corp" → No secrets in prompts, audit required
│
▼
Business Unit: "Analytics" → Low temperature, consistency mode
│
▼
Team: "Reporting" → 9-6 EST only, approved data sources
│
▼
Caller: "user:alice" → GPT-3.5, 500 tokens, standard clearance
or "app:report-bot" → GPT-4, 2000 tokens, automated access
Final Policy = Intersection of ALL levels
─────────────────────────────────────────
Alice gets: GPT-3.5, 500 tokens, 9-6 EST, no secrets,
standard clearance, approved sources only, full auditMonotonic Restriction
Policies can only become more restrictive as you go down the hierarchy. A team cannot grant permissions that the company policy forbids. This is mathematically enforced — not just convention.
Security Guarantees
MACAW provides five formal security objectives:
Authentication
Every operation is bound to a verified principal. No anonymous actions, no shared credentials. User identity flows through the entire workflow.
Authorization
Operations execute only if permitted by applicable policies. Hierarchical policies compose with monotonic restriction — child policies can only restrict, never expand.
Audit
Complete, tamper-evident record of all operations. Every boundary crossing is logged with cryptographic signatures for non-repudiation.
Integrity
Operations cannot be modified in transit. Cryptographic signatures ensure end-to-end integrity from request to execution.
Isolation
Compromising one component doesn't compromise others. PEP independence ensures blast radius is limited to a single scope.
What This Means in Practice
| Attack | Boundary | Defense Class | Protection |
|---|---|---|---|
| Prompt injection | S1 (Prompt) | By-policy | Content policy evaluation |
| Identity spoofing | All | By-design | Signature verification |
| Privilege escalation | S2 (Tool) | By-policy | Permission check at invocation |
| Session replay | All | By-design | Nonce + timestamp validation |
| Data exfiltration | S3 (Data) | By-policy | Data flow verification |
| Context poisoning | S4 (Context) | By-policy | Attestation chain validation |
| Audit tampering | All | By-design | Append-only + signatures |
Deterministic Security
MACAW provides deterministic verification, not probabilistic detection. Operations either carry valid cryptographic proof and satisfy policies, or they are rejected. No bypass techniques, no gray areas, no "probably safe."
What Makes MACAW Different
| Other Solutions | MACAW |
|---|---|
| Content filtering (probabilistic) | Cryptographic verification (deterministic) |
| Binary allow/deny | Graduated controls (model, tokens, data) |
| Single-operation focus | Workflow governance (multi-step) |
| Agent-level identity | User identity propagation |
| Trust the agent | Zero trust — verify everything |
| Replace your IdP | Extend your existing SSO |
The Bottom Line
MACAW provides deterministic security through mathematical verification. Operations either carry valid cryptographic proof or are rejected. No bypass techniques, no gray areas, no "probably safe."