Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/openagentidentityprotocol/agentidentityprotocol/llms.txt

Use this file to discover all available pages before exploring further.

​
General

AIP (Agent Identity Protocol) is an open standard for secure agentic identity management and authorization. It defines how to declare, enforce, and audit what actions an AI agent can perform.Think of it as IAM (Identity and Access Management) specifically designed for AI agents.
  • AIP Specification (spec/): The protocol standard that anyone can implement
  • Go Proxy (implementations/go-proxy/): One reference implementation of that standard
Think of it like HTTP (the spec) vs Apache/Nginx (implementations). The specification defines the standard, while implementations provide working software.
Yes! AIP is a specification. You can:
  • Implement AIP natively in your MCP client (Cursor, Claude Desktop, etc.)
  • Build your own proxy in any language
  • Use the Go proxy as a reference
The specification is open and language-agnostic.
No. AIP sits between the MCP client and server as a transparent proxy. Your MCP server doesn’t need any modifications.
[Agent] → [AIP Proxy] → [MCP Server]
The proxy intercepts tools/call requests, applies policy, and forwards allowed requests unchanged.
v1alpha2 adds robust security features for production deployments:
  • Identity Tokens: Cryptographic session binding and replay prevention
  • Server-Side Validation: Centralized policy enforcement via HTTP
  • Policy Signatures: Integrity verification for policy files
  • Tool Schema Hashing: Protection against tool poisoning
For local development, v1alpha1 is sufficient. For production, use v1alpha2.
Not for local development. Identity tokens are recommended when:
  • You run agents in a multi-tenant environment
  • You need to audit who (which session) performed an action, not just what happened
  • You are using the centralized AIP Server

​
Security

AIP and workforce AI governance tools solve different problems at different layers:Workforce AI Governance (e.g., SurePath.ai):
  • Monitors employee AI usage across your organization
  • Network/application level visibility
  • Answers: “Who in my org is using ChatGPT? What are they asking?”
  • Typically SaaS platforms for compliance and governance
AIP (Agent Identity Protocol):
  • Controls what actions AI agents can take on your infrastructure
  • Tool-call level authorization (blocks dangerous operations)
  • Answers: “Can this agent delete files? Access production databases?”
  • Open protocol for developers building agents
These are complementary: Use workforce governance to monitor employee AI usage. Use AIP to secure the agents those employees build.
AspectOAuthAIP
GranularityScope-level (“repo access”)Action-level (“repos.get with org:X”)
TimingGrant-timeRuntime (every call)
AudienceEnd usersDevelopers/Security teams
FormatToken claimsYAML policy files
OAuth answers “who is this?” — AIP answers “should this specific action be allowed?”
AIP significantly reduces the blast radius of prompt injection by:
  • Limiting which tools an agent can call
  • Validating arguments with regex patterns
  • Requiring human approval for sensitive operations
  • Logging all decisions for forensic analysis
However, AIP cannot prevent prompt injection itself—it mitigates the consequences. Think of it as defense-in-depth: even if an attacker hijacks the agent, they can’t execute dangerous operations.
Network egress control is planned for AIP v1beta1. Currently, tool-level authorization is enforced but the MCP server subprocess can still make network calls.For maximum security today, run MCP servers in containers with --network=none.
Audit logs are append-only from the agent’s perspective (the agent doesn’t have write access to the log file).For production use, forward logs to an external SIEM or use signed logging for cryptographic verification.

​
Policy

Anywhere you like. Common locations:
  • ~/.config/aip/policy.yaml (user config)
  • ./agent.yaml (project root)
  • /etc/aip/policy.yaml (system-wide)
Pass the path with --policy /path/to/policy.yaml.
It’s blocked with error code -32001 Forbidden. AIP is default-deny.This fail-closed design ensures that unknown or undeclared tools are automatically rejected.
Yes! Use monitor mode:
spec:
  mode: monitor  # Log violations but don't block
Check the audit log to see what would have been blocked. This is useful for testing policies before enforcing them.
Use action: ask:
tool_rules:
  - tool: deploy_production
    action: ask  # Shows native OS dialog
This triggers a human-in-the-loop approval dialog before the tool call proceeds.
Yes, with regex patterns:
tool_rules:
  - tool: postgres_query
    allow_args:
      query: "^SELECT\\s+.*"  # Only SELECT queries
This allows fine-grained control over what arguments an agent can pass to a tool.
  1. Enable spec.server in your policy
  2. Configure TLS (required for non-localhost)
  3. Set failover_mode (recommend fail_closed for security)
See the Server-Side Validation Guide for details.

​
Implementation

When wrapping a Docker container with AIP, signals (SIGTERM/SIGINT) are sent to the docker CLI process, not the container itself. This can leave zombie containers running.Solution: Always use --rm and --init flags:
# Bad - container may not receive signals
aip --policy policy.yaml --target "docker run myimage"

# Good - proper signal handling and cleanup
aip --policy policy.yaml --target "docker run --rm --init -i myimage"
FlagPurpose
--rmAutomatically remove container when it exits
--initRun init process (tini) that forwards signals properly
-iKeep stdin open for JSON-RPC communication
Any MCP client that supports custom server commands:
  • Cursor: Add to ~/.cursor/mcp.json
  • Claude Desktop: Add to claude_desktop_config.json
  • Continue (VS Code): Add to Continue config
  • Custom clients: Use AIP as the server command
The AIP proxy is client-agnostic and works with any MCP-compatible client.
Yes! The Go proxy builds for Windows. Human-in-the-loop (action: ask) uses native Windows dialogs via PowerShell.
  1. Enable verbose mode: --verbose
  2. Check stderr for policy decisions
  3. Review the audit log: cat aip-audit.jsonl | jq .
  4. Use monitor mode to test without blocking
The audit log contains complete information about every policy decision, including why a request was allowed or denied.
Minimal. The proxy adds:
  • ~1-5ms per request for policy evaluation
  • Negligible memory overhead (policies are loaded once)
JSON-RPC parsing and regex matching are fast operations. For most use cases, the overhead is imperceptible.

​
Contributing

See our Security Policy for responsible disclosure instructions.Do not file public GitHub issues for security vulnerabilities.
Yes! We welcome implementations in other languages. Requirements:
  • Pass the conformance test suite (spec/conformance/)
  • Document your implementation
  • Submit a PR to be listed in the registry
See Contributing for details.
  1. Open an issue describing the change
  2. Discuss with maintainers
  3. Submit a PR to spec/AIP-v1alpha1.md
  4. Include conformance tests for new behavior
Specification changes require community consensus and backward compatibility consideration.

Build docs developers (and LLMs) love

Get started for freeTalk to us