Building a Policy Gateway for AI Agent Delegation

April 2026

Your loan approval agent just released funds. Which agent scored the credit? Who assessed the risk? Did the same agent handle both scoring and approval? Can you prove the delegation chain after the fact?

If you're running multi-agent systems on MCP or A2A today, the answer to all of these is no.

I built a gateway that makes the answer yes.

Protocols don't get adopted. Products do.

The Agent Identity Protocol (AIP) solves delegation verification at the protocol level. Invocation-bound capability tokens, Ed25519 signatures, Datalog policy evaluation, append-only delegation chains. The cryptography works. The previous article covers the theory.

But theory doesn't get deployed. Asking every team to install an SDK, rewrite their agent code, understand a new protocol, and update their deployment pipeline is too much friction. That's not how enterprise security tools get adopted.

They get adopted as boundary controls. A platform team puts a proxy in front of a system, configures a policy file, and the system is protected. No application team changes anything. That's how API gateways work. That's how WAFs work. That's how this should work.

The policy is the product

The gateway reads a YAML policy file. No code. The file declares three things: who your agents are, what each one can do, and what workflow constraints apply.

agents:
  credit-scorer:
    identity: "aip:key:ed25519:zScorer..."
    can_delegate:
      - tool:check_credit

  loan-approver:
    identity: "aip:key:ed25519:zApprover..."
    can_delegate:
      - tool:approve_loan

rules:
  - action: tool:approve_loan
    requires:
      - tool:check_credit
      - tool:assess_risk
    deny_if:
      - same_actor: [credit-scorer, loan-approver]

Scope. Each agent has an explicit capability list. The credit scorer can call check_credit and nothing else. Not because the code limits it, but because the policy does.

Prerequisites. You can't approve a loan without a credit check and risk assessment in the delegation chain. The requires rule enforces this.

Separation of duties. The agent that scores credit can't also approve the loan. same_actor is maker-checker enforcement at the protocol level.

These are boring, readable rules. That's the point. Policy languages die when the first experience is too academic.

Six things happen on every request

Step 5 is what makes this practical for existing systems. After verification, the gateway strips any spoofed identity headers and injects its own:

X-AIP-Verified: true
X-AIP-Subject: aip:key:ed25519:zScorer...
X-AIP-Scope: tool:check_credit
X-AIP-Depth: 1

The upstream MCP server reads X-AIP-Subject and knows who's calling. No SDK needed. A simple header check. The gateway becomes a zero-trust boundary that enriches every request with verified caller identity.

Proof: loan origination pipeline

Four agents. Four scenarios. One gateway. This is the actual output.

Scenario 2 is the headline. The credit scoring agent tried to call approve_loan. The gateway checked the policy, found that tool:approve_loan is not in the scorer's capability list, and blocked it. The audit log records exactly what happened, who tried it, and why it was denied.

Scenario 3 is what regulators care about. Even an agent with the right scope can't skip due diligence. The requires rule enforces that approval needs a credit check and risk assessment in the chain first.

Scenario 4 is separation of duties. The same identity can't play two conflicting roles. This is maker-checker enforcement that banks have required for decades, now applied to autonomous agents.

Why a gateway, not an SDK

SDKs require developers to change code. That means every team needs to understand the protocol, update their agents, test the integration, and deploy. In a large organization, that's months of coordination.

A gateway requires one platform team to deploy a proxy and write a policy file. Application teams change nothing. Their agents keep working exactly as before. The gateway is invisible to them.

This is how adoption happens in enterprises. Not through voluntary library adoption across every team, but through a boundary control that one team can deploy.

MCP OAuth tells the tool who can access it. AIP Gateway tells the tool whether this specific delegated action should be allowed. They answer different questions and deploy together.

The audit trail enterprises actually need

Every decision produces a JSON line with full context:

{
  "decision": "deny",
  "tool": "tool:approve_loan",
  "subject": "aip:key:ed25519:zScorer...",
  "scope": ["tool:check_credit"],
  "depth": 1,
  "request_id": "uuid-456",
  "reason": "tool:approve_loan not in can_delegate"
}

Who requested what. When. Whether it was allowed or denied. Why. Pipe it to your SIEM, your compliance dashboard, or just grep the file. This is the format that audit, compliance, and security teams already know how to consume.

Get started

pip install aip-gateway
aip-gateway serve --policy policy.yaml

Or run the full loan origination demo:

git clone https://github.com/sunilp/aip-gateway
cd aip-gateway && pip install -e ".[dev]"
python examples/loan_origination/run_demo.py

Or use Docker:

docker run -v ./policy.yaml:/etc/aip-gateway/policy.yaml \
  -p 8090:8090 jamjetdev/aip-gateway