Docs/Deep Dive/Distributed PEPs

Distributed PEPs

Policy Enforcement Points at every boundary. The receiver verifies—not the sender. This prevents agents from "grading their own homework."

The Self-Verification Problem

In naive agentic architectures, an agent verifies its own requests before executing tools. This is like asking a student to grade their own exam—there's an obvious conflict of interest.

Naive Approach

# Vulnerable: agent verifies itself
agent.verify(agent.sign(request))
# Always passes!

A compromised agent can forge credentials, bypass restrictions, and execute unauthorized operations. The security boundary exists only in name.

MACAW Approach

# Secure: tool verifies agent
tool.verify(agent.sign(request))
# Independent verification!

The tool (receiver) verifies the request. It has no incentive to forge—it's just executing the operation. Independent verification is the key insight.


Receiver-Side Verification

MACAW implements PEPs at endpoints. Every tool/LLM endpoint is a Policy Enforcement Point with its own identity and cryptographic keys.

When a request arrives, the endpoint independently verifies the signature by looking up the caller's public key from the Agent Registry—never from the request itself.

Agent
signs request
invocation
Endpoint
verifies + enforces
1
Receive
signed request
2
Lookup
public key
3
Verify
signature
4
Enforce
policy

What Each PEP Does

Each endpoint is a full security boundary with its own cryptographic identity:

CapabilityDescription
Own IdentityHas its own keypair, registers in Agent Registry, can sign responses
Signature VerificationLooks up caller public key from Registry, verifies request signature
Policy EnforcementEvaluates MAPL policies independently, enforces tool-specific restrictions
Attestation CreationCreates signed attestations after execution for audit and conditional policies
Audit LoggingLogs all decisions and operations to events.log and audit.log

The Zero Trust Mesh

When every endpoint is a PEP, you have a zero-trust mesh where every boundary is a verification point. No implicit trust at any point.

  • No Single Point of Failure: Compromising one agent doesn't compromise the system
  • Defense in Depth: Multiple verification layers, breaking one doesn't break the chain
  • Least Privilege: Each endpoint enforces only the permissions it needs
  • Complete Audit Trail: Every PEP logs its decisions
Trust Mesh Verification Flow:

Agent A ──sign──→ Tool X ──verify──→ Execute
    │                │
    │                └──sign──→ LLM Y ──verify──→ Execute
    │                              │
    └──sign──→ Tool Z ──verify──→ Execute

Each arrow is a verification point:
• Sender signs with private key
• Receiver verifies via Registry lookup
• Policy evaluated independently
• Decision logged for audit

Agent Registry

The Agent Registry (part of the Trust Layer Control Plane) stores public keys for all registered agents. When an endpoint needs to verify a signature, it looks up the caller's public key from the Registry—never from the request itself.

This is the Trusted Computing Base (TCB). Its integrity is critical for the security of the entire mesh.

FunctionDescription
registerRegister agent with public key, type, sandbox, policies
lookupRetrieve agent record by ID for signature verification
unregisterRevoke an agent (expired sessions, compromised keys)
cleanupAutomatic removal of expired registrations

The Key Insight

Verification by the receiver, not the sender. This simple principle is what makes MACAW secure. A compromised agent cannot bypass security because it's not the one doing the verification. The tool—which has no incentive to forge—independently verifies every request against the Registry.

This is how MACAW achieves zero trust from first principles: every boundary crossing is independently verified by the party that has no incentive to lie.


Related