undefined | Amla Labs Blog

The Delegation Problem No One Is Solving

Multi-agent AI is everywhere. From YC batches to enterprise labs, nearly every AI startup is discovering they need specialized agents working together: research agents spawning analysis sub-agents, financial assistants delegating to trading executors, customer support orchestrators routing to domain-specific experts.

But there’s a critical security gap that almost no one is addressing:

How do you safely let Agent A delegate credentials to Agent B without creating a security nightmare?

Every AI engineer building multi-agent systems hits this wall. When your research agent needs to give its data analysis sub-agent access to your production database, what do you do?

Current options all fail:

Share your OAuth token → Both agents have full access forever
Give the same Vault credentials → Can’t tell who did what
Route everything through a proxy → Adds latency on every request
Use environment variables → Every child process sees every secret

None of these were designed for agent-to-agent delegation. And the security implications are serious.

The Attack That Proves This Isn’t Theoretical

Security researchers have demonstrated “Agent Session Smuggling”—attacks where malicious agents steal credentials mid-session and use them for unauthorized actions.

Proof-of-concept exploits show:

💣 Attack 1: Customer Data Exfiltration

A compromised research agent steals a financial assistant’s credentials mid-collaboration and exfiltrates customer conversations from the production database.

💣 Attack 2: Unauthorized Trading

The same research agent uses stolen credentials to place unauthorized trades using a trading executor’s API access.

The critical gap? Current security solutions (OAuth, Vault, proxies) weren’t designed to prevent agent-to-agent credential theft.

Industry security researchers recommend:

“Cryptographically signed agent credentials with limited-use enforcement and provable delegation chains.”

That’s exactly what we’re building at Amla Labs.

Why Existing Solutions Fall Short

OAuth and Token-Based Systems

OAuth provides industry-standard authentication with scope-based permissions, but bearer tokens can be copied and reused indefinitely—anyone who obtains one can use it

# OAuth token example - works until it expires
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

# Problem: If Agent A gives this to Agent B,
# Agent B can use it hundreds of times until expiration
# No way to limit "use this exactly once" or "use this 5 times max"

OAuth was designed for humans logging into websites, not agent-to-agent delegation. Key limitations:

No usage limits: Can’t enforce “use this token exactly 10 times then stop”
Coarse permissions: read:database means all tables, not specific ones
No delegation chain: Can’t prove Agent C legitimately got access from B from A
Requires network access: Every verification needs a round-trip to the auth server

Secret Managers

Vault and AWS Secrets Manager provide encrypted storage with audit logging, but they’re designed for storing secrets, not managing delegation

# Vault approach - everyone gets the same password
secret = vault.read("database/prod/credentials")
# → {"password": "hunter2"}

# Problems:
# 1. Agent A and Agent B get identical credentials
# 2. If one agent shares it, you can't tell from logs
# 3. Can't give "read-only to 2 tables" vs "full access"
# 4. No proof that Agent A intentionally delegated to Agent B

Vault solves secure storage, but not delegation:

Can’t give Agent B a weaker version of Agent A’s credentials
Can’t enforce usage limits like “5 times, then stop”
Audit logs show accesses, not delegation relationships
Credential sharing is invisible—looks like independent access

Proxy Services

Proxy services like Multifactor and Aembit provide centralized gateways that mediate agent-to-API access, but bearer tokens remain vulnerable and proxies create bottlenecks

Agent A → Proxy (gets bearer token) → External API
Agent B → Proxy (gets bearer token) → External API
# If Agent A shares its token with Agent B, proxy can't tell

Proxies add a layer of indirection but don’t solve the fundamental problem:

Bearer tokens can still be exfiltrated and reused
Centralized proxy creates a single point of failure
Added latency on every request (20-100ms vs 1-3ms for cryptographic verification)
Can’t work offline or in airgapped environments

Environment Variables

The Promise: Simple, ubiquitous

The Reality: Insecure and impossible to audit

# Every agent in the process tree sees these
export DATABASE_PASSWORD=hunter2
export API_KEY=sk-1234567890

# No way to know:
# - Which agent accessed which secret
# - Whether credentials were exfiltrated
# - Who delegated access to whom

Environment variables are the worst option:

Plaintext storage in memory
No access control whatsoever
Zero audit trail
All child processes inherit all secrets

The Solution: Capability-Based Credentials

We need a fundamentally different approach to agent delegation.

Not bearer tokens that can be copied indefinitely. Not shared secrets that every agent sees. Not centralized proxies that bottleneck every request.

We need unforgeable references to resources with cryptographically enforced constraints—credentials that automatically weaken as they’re delegated, with built-in usage limits and audit trails.

This isn’t new theory. It’s proven technology.

Operating systems solved this problem 40 years ago with capability-based security. seL4 microkernels use capabilities to achieve formal verification—mathematical proof that the system is secure.

Now we’re bringing those principles to AI agents.

How Capabilities Work

# Parent agent creates a capability
parent_capability = {
  "capability_id": "cap-root-abc",
  "interfaces": ["database:*", "api:*"],
  "allowed_actions": ["read", "write", "delete"],
  "allowed_params": {},
  "max_uses": null,  # Unlimited
  "signature": "Ed25519(private_key, ...)",  # Cryptographically unforgeable
}

# Agent A creates a LIMITED capability for Agent B
derived_capability = parent_capability.derive({
  "agent_id": "agent_b",
  "interfaces": ["database:read"],  # Only reading, no writes
  "allowed_actions": ["query", "search"],
  "allowed_params": {"table": "customers"},  # Only this table
  "max_uses": 1,  # Use exactly once, then invalid
  "nonce": "0x1234...",  # Cryptographic proof of single use
})

Key Properties That Make This Bulletproof

✅ Unforgeable: Military-grade signatures (Ed25519) mean tampering = instant detection
✅ Progressive Attenuation: Child agents get fewer permissions, never more (mathematically enforced)
✅ Limited-Use Enforcement: Use a credential 10 times? It dies after the 10th use. No exceptions.
✅ Provable Audit Trail: Cryptographic proof shows: “Root gave to A, A gave to B, B used it 3 times”
✅ Works Offline: No phone home required—verify credentials without internet access

Real-World Example

# Orchestrator (root capability)
orchestrator = AmlaClient(root_capability="cap-root-123")

# Spawn research agent with read-only database access
research_agent = orchestrator.spawn_agent(
    agent_id="research_001",
    capabilities={
        "database:read": {
            "tables": ["customers", "transactions"],
            "max_uses": 100,
            "expires_in": "1h",
        }
    }
)

# Research agent needs to delegate to data analysis agent
# Can only give a subset of its own permissions
analysis_agent = research_agent.delegate_to(
    agent_id="analysis_001",
    capabilities={
        "database:read": {
            "tables": ["transactions"],  # Subset of parent's tables
            "actions": ["aggregate_only"],  # More restrictive
            "max_uses": 10,  # Fewer uses
            "expires_in": "30m",  # Shorter expiration
        }
    }
)

# If research_agent tries to give MORE permissions than it has,
# the gateway rejects the capability derivation

How This Stops Palo Alto’s Attack

Palo Alto’s attack works because stolen credentials can be reused. Agent exfiltrates token → replays it 1000 times for unauthorized actions.

Capabilities break this at multiple independent layers:

# Malicious agent steals capability from victim
stolen_capability = exfiltrate(victim_agent)

# Attack Layer 1: Limited-use enforcement
# First use: works (uses 1/1)
result1 = gateway.execute(stolen_capability, action="query")

# Second use: DENIED (already used once)
result2 = gateway.execute(stolen_capability, action="query")
# ❌ Error: UsageLimitExceeded (credential already consumed)

# Attack Layer 2: Unforgeable signatures
# Attacker tries: "I'll just change max_uses to 999!"
stolen_capability.max_uses = 999
gateway.verify(stolen_capability)
# ❌ Error: InvalidSignature (tampering detected instantly)

# Attack Layer 3: No privilege escalation
# Attacker tries: "I'll add write permissions!"
stolen_capability.interfaces = ["database:write"]
# ❌ Error: InvalidSignature (can't modify without gateway's private key)

Defense in depth. Even if one layer fails, three others catch the attack.

Implementation Challenges

Building cryptographic capability systems for distributed agent architectures involves several engineering challenges:

The Engineering Problems

🔥 Distributed Usage Tracking Enforcing “max 10 uses” across 50 servers handling concurrent requests? Race conditions everywhere. We use PostgreSQL’s SERIALIZABLE isolation with atomic counters—no double-spending, ever.
⚡ Cryptographic Performance RSA signatures are slow (tens of milliseconds). Ed25519 is fast (sub-millisecond verification). That’s the difference between a bottleneck and production-ready. We use battle-tested C libraries (libsodium) wrapped in safe Python bindings.
🎯 Developer Experience Writing JSON to derive capabilities? Tedious and error-prone. Phase 3 brings Agent Cards: describe your task in English, get a minimal-privilege capability automatically.
🔌 Backwards Compatibility Your AI framework expects OPENAI_API_KEY=sk-123? We wrap capabilities in familiar formats. Drop-in replacement, zero code changes required.
📜 Compliance & Audit Regulator asks: “Why did Agent B access customer data?” We show the cryptographic chain: Root → A (reason: research) → B (reason: analysis) → read customers table. Tamper-proof.

This is why competitors are bolting OAuth onto agents instead. By the time they realize it doesn’t work, we’ll have a 2-year engineering lead.

Our Roadmap

Phase 1 (Foundations): Secure credential storage with basic capabilities

Encrypted secret storage
MCP integration
Manual capability creation

Phase 2 (Core Differentiation): Full delegation with limited-use enforcement

Cryptographic capability derivation
Usage tracking registry (PostgreSQL SERIALIZABLE transactions)
Audit logging with provable delegation chains

Phase 3 (Enterprise Features): Auto-attenuation via Agent Cards

LLM-powered permission extraction from task descriptions
Automatic constraint generation
Reasoning storage for compliance

The Market Opportunity: A Growing Problem

Multi-agent AI companies are discovering the delegation problem as they scale. From startups to enterprises, teams building agent systems hit this wall.

Current Market Landscape

Incumbents (Vault, AWS Secrets Manager):

Solving credential storage, not agent delegation
Can’t track which agent accessed what or why
No cryptographic proof of delegation chains

Startups (Keycard, Multifactor, Aembit):

Bolting OAuth onto agents
Still vulnerable to credential theft and replay attacks
Centralized proxies create bottlenecks and single points of failure

No one is solving the cryptographic delegation problem with limited-use enforcement and provable audit trails.

Our Unfair Advantage

By the time competitors realize OAuth doesn’t work for agents (12-18 months from now when Palo Alto’s research goes mainstream), we’ll have:

✅ 2-year engineering lead on distributed nonce registries
✅ Reference implementations for CrewAI, LangChain, AutoGen
✅ Enterprise customers with compliance requirements proving ROI
✅ Network effects from Agent Card marketplace (Phase 4)

This market doesn’t exist yet. We’re defining it.

Follow Along

We’re building in the open. Development roadmap, design docs, and (soon) code are on GitHub.

GitHub: github.com/amla-labs (star to follow progress)
Design Partners: If you’re building multi-agent systems, let’s talk
Next Post: How seL4 microkernel principles apply to AI agents

Amla Labs is building capability-based credentials for AI agents. We’re backed by experience building Apple Core OS and researching formally verified systems. Currently seeking design partners and enterprise security co-founders.