← AIP

AIP Security Model

What AIP defends against, what it does not, and how the security self-audit works.

Threat model

AIP is designed to address specific threats in multi-agent systems communicating over MCP. The following are explicit design targets.

Agent impersonation

Ed25519 signatures prove identity. A token signed by Agent A cannot be forged by Agent B without access to Agent A's private key.

Scope escalation

Delegation chains are append-only. Each hop can only narrow scope -- fewer tools, lower budget, shorter TTL -- never widen it. A delegated agent cannot grant itself permissions its parent did not have.

Delegation abuse

Depth limits cap how far delegation chains can extend. Budget ceilings prevent runaway spending. Both are enforced cryptographically, not by convention.

Replay attacks

Short-lived tokens (recommended TTL under 1 hour) with expiry checking prevent replayed tokens from being accepted after their window. No revocation lists required.

Token tampering

Any modification to a compact (JWT) or chained (Biscuit) token invalidates the cryptographic signature. The verifier detects the tampering before processing the claims.

Chain integrity

In chained tokens, every block in the delegation chain is independently signed. A missing, reordered, or modified intermediate block breaks the entire chain. There is no way to silently drop a delegation step.

What AIP does not defend against

Honest security documentation includes the limits. These are outside AIP's threat model.

Compromised runtime

If the agent's process is compromised, the attacker has access to the private key. AIP cannot protect keys from an attacker with process-level access.

Key exfiltration

AIP does not manage key storage. If keys are stored insecurely (plaintext files, unencrypted environment variables), they can be stolen. Key management is the operator's responsibility.

Side-channel attacks

Timing attacks on token verification are not mitigated. AIP defers to the underlying cryptographic libraries (cryptography, ed25519-dalek) for constant-time guarantees.

Malicious authorized agents

If an agent is authorized to call a tool, AIP cannot prevent it from misusing that access within its granted scope. Authorization is not intent verification.

Network-level attacks

AIP assumes TLS for transport. Without TLS, tokens can be intercepted and replayed within their TTL window. Always deploy behind TLS.

Security self-audit

The AIP MCP proxy runs a security self-audit on every token verification. This goes beyond simple validity checks (signature, expiry, scope) to flag tokens that are technically valid but hygienically problematic.

The audit checks:

The audit returns structured JSON with three fields: passed (boolean), warnings (list), and errors (list). Errors fail the token; warnings are logged but do not block the request by default.

Example audit result for a clean token:

{
  "passed": true,
  "warnings": [],
  "errors": []
}

Example audit result for a token with hygiene issues:

{
  "passed": true,
  "warnings": [
    "TTL is 86400s (24h 0m), exceeds recommended maximum of 3600s",
    "Wildcard scope '*' grants unrestricted access",
    "Budget $50.00 exceeds recommended maximum of $10.00"
  ],
  "errors": []
}

Example audit result for an invalid token (empty scope):

{
  "passed": false,
  "warnings": [],
  "errors": [
    "Empty scope: token authorizes no actions"
  ]
}

To run the audit directly:

from aip_mcp.audit import audit_compact, audit_chained

result = audit_compact(verified_token)
print(result.to_dict())

Token hygiene recommendations

Passing the self-audit is the minimum bar. These practices reduce the blast radius of any compromise.

Delegation chain security

Chained tokens (Biscuit format) are the primary mechanism for multi-hop agent delegation. Their security rests on one invariant: blocks are append-only and each block can only restrict, never expand, the permissions of the previous block.

Scope attenuation example:

An orchestrator agent holds a token with scope [search, email, browse]. It delegates to a researcher agent, attenuating scope to [search] only. The researcher forwards that token to a tool server. The tool server verifies the full chain:

# Orchestrator token (authority block)
scope: ["tool:search", "tool:email", "tool:browse"]
budget: $5.00

# Researcher delegation (block 1 -- added by orchestrator)
scope: ["tool:search"]          # narrowed
budget: $1.00                   # narrowed

# Tool server verification
# Full chain verified: orchestrator signed block 0,
# orchestrator signed the attenuation in block 1.
# Researcher cannot add back tool:email -- adding it would
# require a valid signature from the orchestrator.

Budget narrowing:

# Orchestrator: $5.00
# -> Researcher: $1.00
# -> Sub-agent: $0.50
#
# Each delegation block locks in a tighter ceiling.
# The tool server sees $0.50 as the effective budget.

What happens when someone tries to widen scope: any modification to a Biscuit block requires re-signing with the key that created that block. An attacker without the orchestrator's private key cannot add permissions to an existing delegation block. Attempting to insert or modify a block produces a chain where the Biscuit signature verification fails immediately.

Comparison with OAuth/OIDC

OAuth 2.1 and OIDC are the dominant identity protocols for web services. AIP is not a replacement -- it addresses a different problem: cryptographic identity and multi-hop delegation for agent-to-agent calls in MCP contexts.

Aspect OAuth 2.1 AIP
Identity Opaque tokens or JWT Ed25519 keypairs (self-certifying)
Delegation Not natively supported Cryptographic chain (Biscuit blocks)
Multi-hop No Yes -- each hop adds a signed block
Scope model Opaque string scopes Datalog policies (auditable, composable)
Revocation Token revocation lists Short-lived tokens (no revocation lists)
MCP support Single-hop only Full delegation chain across MCP hops

OAuth 2.1 works well for user-facing authorization flows. AIP targets machine-to-machine agent identity where chains of delegation need to be verifiable end-to-end.

Responsible disclosure

If you discover a security vulnerability in AIP, please report it privately. Do not open a public GitHub issue.

Email: sunil@sunilprakash.com

Please include a description of the vulnerability, steps to reproduce, affected versions, and potential impact. Receipt will be acknowledged within 48 hours; critical issues will receive a fix or mitigation within 7 days.

Read the full security policy on GitHub →

Related