Skip to main content
This document explains the security challenges that AIP addresses and why existing solutions are insufficient.

​
The Problem: God Mode by Default

Modern AI agents operate with unrestricted access to powerful tools. When you grant an LLM access to your GitHub account, database, or cloud infrastructure, you’re not just giving it an API key—you’re granting unbounded intent execution with no policy layer.

​
The Threat Model

ThreatDescriptionReal-World Example
Indirect Prompt InjectionMalicious instructions embedded in data the agent processesGeminiJack (2024): Attackers embedded prompts in Google Docs that hijacked Gemini’s actions
Consent FatigueUsers approve broad permissions without understanding scope”Allow GitHub access” grants repo:delete, not just repo:read
Shadow AIAgents operating outside enterprise security boundariesDevelopers running local Copilot instances with production credentials
Privilege EscalationAgents accumulating permissions across tool callsAgent chains: Slack → Calendar → Email → sends unauthorized messages
Data ExfiltrationSensitive data leaving through unmonitored egressAgent “summarizing” code by posting to external APIs

​
API Keys Are for Code. AIP Is for Intent.

Traditional security assumes deterministic code execution. API keys authenticate the application. But LLMs are non-deterministic systems executing user intent through model interpretation. 
Traditional: Code → API Key → Resource
    └── Deterministic, auditable, predictable

Agent World: User Intent → LLM Interpretation → Tool Call → Resource
    └── Non-deterministic, opaque, emergent behavior
We need a security primitive that authenticates and authorizes intent, not just identity.

​
Security Comparison

AspectStandard MCPAIP-Enabled MCP
AuthenticationStatic API keysShort-lived OIDC tokens
AuthorizationNone (full access)Per-action policy check
ScopeImplicit (whatever key allows)Explicit manifest declaration
AuditApplication logs (if any)Immutable, structured audit trail
Egress ControlNoneNetwork-level filtering (planned)
RevocationRotate API keysInstant token/session revocation
Human-in-the-LoopNot supportedConfigurable approval gates
Blast RadiusUnlimitedScoped to manifest
ComplianceManual attestationPolicy-as-code, auditable

​
Why Not Just Use…?

​
OAuth Scopes?

OAuth scopes are:
  • Coarse-grained: “repo access” vs “read pull requests from org X”
  • Static: Granted at install time, can’t change per-session
  • User-facing: Leads to consent fatigue
AIP policies are:
  • Fine-grained: Per-tool, per-argument validation
  • Dynamic: Can change without re-authentication
  • Developer-controlled: Defined in config files, version-controlled

​
Service Mesh (Istio)?

Service meshes operate at the service level, not the action level. They can say “Service A can call Service B” but not “Agent can only call repos.get with org:mycompany/*”. AIP operates at the tool call level within a service.

​
Container Sandboxing?

Containers provide process isolation but not semantic authorization. A containerized agent with network access can still exfiltrate data. AIP provides policy-based authorization that understands what the agent is trying to do.

​
Comparison Table

ApproachAuthenticationAuthorizationAuditRevocation
Raw API KeysStatic tokenNoneApp logsRotate everywhere
OAuth ScopesToken-basedCoarse-grainedVariesToken expiry
Service Mesh (Istio)mTLSService-levelYesCertificate rotation
AIPShort-lived OIDCPer-action policyImmutable trailInstant session kill
AIP is purpose-built for the unique challenge of non-deterministic AI agents executing user intent.

​
Architecture Principles

  1. Defense in Depth: Multiple independent security layers (identity, policy, egress, audit)
  2. Least Privilege by Default: Agents start with zero capabilities; everything is opt-in
  3. Fail Closed: Unknown actions are denied; network errors = deny
  4. Immutable Audit: All decisions logged; logs cannot be modified by agents
  5. Human Sovereignty: Critical actions require human approval
  6. Manifest Portability: Same manifest works across runtimes (local, Kubernetes, serverless)

​
Prior Art & Inspiration

AIP builds on established security patterns:
  • SPIFFE/SPIRE: Workload identity framework — AIP extends this to agent identity
  • Open Policy Agent: Policy-as-code — AIP’s policy engine draws from OPA’s design
  • Istio: Service mesh authorization — AIP applies mesh principles to agent traffic
  • AWS IAM: Fine-grained permissions — AIP manifests are IAM policies for agents
  • OAuth 2.0 / OIDC: Token-based identity — AIP leverages OIDC for federation

​
Next Steps