How to secure agentic AI with Agent Identity Protocol (AIP)

An open source framework for least-privilege permissions and audit trails in agentic AI.

Co-author: Carlos Eduardo Arango Gutierrez

When OpenClaw took over the internet by storm, the first thing that came to mind was. Wow! Followed by, are we really just going to let AI run our daily lives? 

The answer, as shown by the market, is a resounding yes. 

When innovation moves fast in the tech space, it usually follows a trend, a pattern some might say, of forgetting something a little important. I have a feeling we all know what I’m talking about.  

When users were mass installing OpenClaw, security engineers were yelling into the abyss that giving full access to a black box assistant was not the most responsible decision an individual could make. As many security personnel know, that’s a risk many users are willing to take. The risk appetite has greatly increased as to not fall behind in the rapid pace of innovation that AI is producing. If Chief Information Security Officers (CISOs) previously thought that their attack surface was huge, well, AI has expanded it greatly.  

The thing is, how can we secure systems when we know that people are still going to use it? Security has historically been seen as a bottle neck for many teams to adopt, simply on the basis that it’s expensive, time consuming, and adds in more steps to what would otherwise be a frictionless user experience. This is especially true for teams without a cyber engineer, someone who can bake resilience into the beginning architecture. The end user, after all, only cares about the results. This issue is what led to the development of the Agent Identity Protocol. 

What is Agent Identity Protocol? 

Agent Identity Protocol (AIP) is an open source standard that is currently being proposed to the IETF working group and looking for more collaborators and contributors to build out secure agentic AI. This framework is built on a two layer model, a layer 1 identity layer and a layer 2 tool call enforcement layer. It’s language agnostic so that anyone can implement it, and we’re building out SDKS and implementations so that people can use it with their existing environments.  

The rationale behind the AIP design is as follows. 

1. We want to know that something hitting the API or committing actions across the internet on behalf of a user is clearly delineated as AI (Layer 1) 
2. We want to enable permissions for the AI like we would an intern. What can it access and do? (Layer 1 and Layer 2 bridge) 
3. How can we hold the AI accountable for malicious actions that occur? i.e how can we capture the intent behind the agent’s actions? (Layer 2) 

These initial steps are what led to the two step layer of AIP. We have to know who the agent is, and we have to know what permissions it has, and then we have to clearly enforce the layer. In addition, we wanted to build in auditing for accountability. The beauty of having this as an open source framework and standard is that we can help build this more clearly to see what developers and AI users need in terms of security support.  By bringing this to the IETF as well, we also gain the ability for consensus to see if this is an applicable model to adopt for agentic security. 

The problem: AI agents are running without guardrails

Today’s agents typically operate in unbounded permissions. When a user grants an LLM access to a service like GitHub or a production database, the agent often receives “God mode” with no policy layer governing what it can actually do. The threat model is broad and real, ranging from indirect prompt injection (where malicious instructions hidden in data hijack an agent’s behavior) to privilege escalation across chained tool calls, consent fatigue from overly broad permission prompts, and silent data exfiltration through unmonitored channels. Traditional security primitives like API keys were designed for deterministic code execution. They authenticate the application, not the intent. But LLMs are non-deterministic systems interpreting user intent through model reasoning, which means the gap between what’s authorized and what actually happens can be enormous. AIP was built to capture the intent and provide a proxy layer that provides and follows defense in depth principles. 

AIP closes that gap by introducing a security layer purpose-built for agentic AI by enforcing per-action authorization with explicit manifest declarations, short-lived tokens, configurable human-in-the-loop approval gates, and immutable audit trails. Its architecture follows a least-privilege-by-default model: agents start with zero capabilities, unknown actions are denied, and network errors fail closed. Drawing inspiration from established infrastructure patterns for fine-grained permissions, AIP adapts to govern what an AI agent is trying to do and not just where it’s allowed to connect. 

Read more: The AI slop problem threatening open source maintainers

Tutorial: Securing an MCP filesystem server with the AIP go proxy 

Currently, the AIP specs are built out, but GitHub only has implementations for the Layer 2 enforcement layer. AIP is always looking for contributors who can help with Layer 1 integration! 

To see how the AIP Layer 2 works in practice, let’s walk through a concrete scenario. Suppose you’re using Cursor (or Claude Desktop) with an MCP filesystem server that gives your AI agent read and write access to a project directory. Without AIP, the agent has full, unconstrained access to every tool the server exposes. It can read files, write files, delete files, and execute commands, all under your credentials with no policy check. The AIP Go Proxy sits between the MCP client (your AI agent) and the MCP server as a JSON-RPC interceptor, evaluating every tools/call request against a policy you define before it ever reaches the server. 

This is the same pattern used in production. The proxy intercepts stdin/stdout JSON-RPC traffic, checks tool calls against your policy, and either forwards, blocks, or prompts for human approval. For this quick start, we can use a simple echo server as the MCP target so you can see the enforcement in isolation without needing any external services. 

Prerequisites 

• Go 1.25+ 
• Python 3.x 

Let’s start by building the proxy, creating a policy, and testing it.

Step 1: Build the proxy 

Clone the repository and build the binary: 

git clone https://github.com/openagentidentityprotocol/aip-go.git 
cd aip-go 
go build -o aip-proxy ./cmd/aip-proxy 

This produces the binary that wraps any MCP server with policy enforcement. 

Step 2: Create a test policy 

AIP defines enforcement as policy files. This allows one policy per agent, so that agents are expressly scoped. 

Create test/agent.yaml with a minimal policy that only allows the list_files tool: 

apiVersion: aip.io/v1alpha1 
kind: AgentPolicy 
metadata: 
  name: test-policy 
spec: 
  allowed_tools: 
    - "list_files" 
  # "delete_files" is implicitly blocked 

The policy is the open spec behind AIP and allows any proxy to be built, as long as it follows the defense rules that are currently being built. Everything is also explicitly blocked by default for a least privileged model.  

Step 3: Create a Dummy MCP Server 

Create test/echo_server.py for a minimal Python script that acts as a stand-in for a real MCP server. It reads JSON-RPC requests from stdin and echoes them back so you can verify what actually reaches the server. The example server can be found on the GitHub:

https://github.com/openagentidentityprotocol/aip-go/blob/main/test/echo_server.py

The echo server is intentionally permissive and it will happily process any request it receives. The point is to prove that the proxy, not the server, is the enforcement boundary. 

Step 4: Run the proxy 

 Start the proxy with verbose logging enabled: 

./aip-proxy --policy test/agent.yaml --target "python3 test/echo_server.py" —verbose 

The --target flag tells the proxy which MCP server command to spawn as a subprocess. The --verbose flag sends detailed decision logging to stderr so you can observe the policy engine in real time. 

You should see startup output confirming the policy was loaded: 

[aip-proxy] Loaded policy: test-policy 
[aip-proxy] Allowed tools: [list_files] 
[aip-proxy] Started subprocess PID 2850: python3 test/echo_server.py 

Step 5: Test an allowed tool call 

 Send a tools/call request for a tool that’s explicitly in our allowed_tools: 

{"jsonrpc": "2.0", "method": "tools/call", "params": {"name": "list_files"}, "id": 1} 

The proxy evaluates the request, finds the tool in the allowlist, and forwards it to the echo server. You’ll see this in the verbose logs: 

[aip-proxy] → [upstream] method=tools/call id=1 
[aip-proxy] Tool call intercepted: list_files 
[aip-proxy] ALLOWED: Tool "list_files" permitted by policy 

And the response comes back from the echo server through the proxy: 

{ 
  "jsonrpc": "2.0", 
  "id": 1, 
  "result": { 
    "echo": { 
      "jsonrpc": "2.0", 
      "method": "tools/call", 
      "params": {"name": "list_files"}, 
      "id": 1 
    }, 
    "message": "Request received by echo_server" 
  } 
} 

The key detail: the echo server received the full request, confirming the proxy forwarded it transparently.   

Step 6: Test a blocked tool call 

Now send a request for something like delete_files, a tool that is not allowed by policy: 

{“jsonrpc": "2.0", "method": "tools/call", "params": {"name": "delete_files"}, "id": 2} 

The proxy intercepts the request, checks the policy, and immediately rejects it: 

[aip-proxy] → [upstream] method=tools/call id=2 
[aip-proxy] Tool call intercepted: delete_files 
[aip-proxy] BLOCKED: Tool "delete_files" not allowed by policy 

The response returned to the caller is a standard JSON-RPC error: 

{ 
  "jsonrpc": "2.0", 
  "id": 2, 
  "error": { 
    "code": -32001, 
    "message": "Forbidden", 
    "data": { 
      "reason": "Tool not in allowed_tools list", 
      "tool": "delete_files" 
    } 
  } 
} 

Critically, the request never reached the echo server. The proxy stopped it at the policy layer. This is what makes AIP different from application-level logging or after-the-fact monitoring — dangerous calls are prevented, not just observed. 

The security properties at work here are: 

• Fail-closed: Unknown tools are denied by default. If it’s not on the list, it doesn’t get through. 
• Zero trust: Every call is evaluated. There are no cached decisions, no session-level grants, no implicit permissions based on prior calls. 
• Audit trail: All decisions are logged with the tool name and outcome to an immutable JSONL audit log giving you a complete forensic record. 
• Isolation: Blocked requests never touch the target server. The blast radius of a compromised or manipulated agent is scoped to exactly what the policy allows. 

What’s next: Contributing to AIP

AIP is currently in its alpha stage. The above demonstrated an example echo server, but the Layer 2 enforcement layer can be wrapped to target any production MCP server. This project has initially started out for intent enforcement and has now grown to include authentication with tokens so that policies aren’t just defined at the local level. Given the need for agentic security, we hope this run through interests all the engineers out there and can provide further collaboration with the open source community! 

Get started

• GitHub organization: github.com/openagentidentityprotocol
• GitHub repository: github.com/openagentidentityprotocol/agentidentityprotocol
• Start or join a discussion: github.com/openagentidentityprotocol/agentidentityprotocol/discussions
• Website: agentidentityprotocol.io

More from We Love Open Source

• OpenClaw: Anatomy of a viral open source AI agent
• Getting started with OpenClaw: Complex tasks from a simple chat
• Why open source is critical for the continued advancement of new tech
• The AI slop problem threatening open source maintainers
• Stop opening firewall ports and start using identity