Stop AI Agents From Sharing Credentials
Like Humans Share Passwords
Enterprises deploying multi-agent systems face a critical gap: how to let Agent A safely delegate credentials to Agent B without granting permanent access.
Palo Alto Networks Unit 42 (2025) just identified "Agent Session Smuggling" as a critical vulnerability. Their recommended defense—cryptographically signed agent credentials—is exactly what we provide.
Our Approach
Capability-based security from operating systems, applied to AI agent orchestration
Secure Credential Storage
Where do enterprises securely store API keys, OAuth tokens, and database credentials that AI agents need?
- Encrypted secret storage
- Basic audit logging
- MCP integration
Agent Delegation
How to let Agent A safely share credentials with Agent B without granting permanent access?
- Cryptographic capability derivation
- Send-once nonce enforcement
- Progressive privilege attenuation
Auto-Attenuation
Automatically compute minimal permissions from agent task descriptions using LLM-powered reasoning.
- Agent Card auto-parsing
- Context-aware constraints
- Reasoning audit trail
Here's How It Actually Works
Instead of sharing passwords that can be copied infinitely, capabilities work like cryptographically signed tickets that expire and progressively lose power as they're delegated.
How Agents Delegate Capabilities
max_uses: unlimited
resources: ["customers", "transactions"]
max_uses: 100
resources: ["transactions"] ← subset only
max_uses: 10 ← fewer uses
expires_in: 30m ← shorter expiry
🛡️ Security Guarantees
- ✓ Progressive Attenuation: Child capabilities always have fewer permissions
- ✓ Cryptographically Unforgeable: Ed25519 signatures prevent tampering
- ✓ Limited Use: Tokens expire after N uses, preventing replay attacks
- ✓ Audit Trail: Complete delegation chain cryptographically provable
Why This Beats OAuth & Bearer Tokens
Bearer tokens are like photocopies — anyone with a copy has full access. Capabilities are like cryptographically signed tickets that can't be forged. Let's compare how they handle agent delegation.
Traditional Auth vs. Capability-Based Security
See how capability-based security prevents the vulnerabilities inherent in bearer token systems
❌ OAuth / Bearer Tokens
Vulnerable to Session Smuggling- Token can be replayed 1000s of times
- Stolen credentials = full access
- No way to limit uses
- Can't prove delegation chain
- Requires online auth server
✅ Capability-Based Security
Session Smuggling Prevented- Limited use enforcement (10 uses → dead)
- Stolen token = minimal blast radius
- Ed25519 signatures prevent forgery
- Provable delegation chain
- Offline cryptographic verification
The Key Difference
Bearer tokens are like photocopies — anyone with a copy has full access. Capabilities are like cryptographically signed tickets — they expire, can't be forged, and progressively lose power as they're delegated.
The Magic: Progressive Privilege Reduction
Each time a capability is delegated, permissions automatically reduce. Watch how a root capability becomes progressively weaker—and why attackers can't reverse this process.
Progressive Privilege Attenuation
Watch how permissions automatically reduce as capabilities are delegated down the chain
capability.attenuate(...) capability.attenuate(...) Cannot Escalate Privileges
If Agent B tries to create a capability with MORE permissions:
child.attenuate({
interfaces: ["database:write"], // ❌ Not in parent!
max_uses: 1000 // ❌ More than parent!
})
→ Error: AttenuationViolationError ⚖️ The Principle of Least Privilege
Each agent receives only the minimum permissions needed for its specific task. As capabilities flow down the delegation chain, they can only become more restrictive, never more permissive. This prevents privilege escalation attacks at the cryptographic level.
Why Existing Solutions Fail
❌ OAuth / Keycard
Bearer tokens can be replayed if exfiltrated. No cryptographic send-once guarantees.
❌ Secret Managers (Vault, AWS)
Not agent-aware. Can't track per-agent access. No support for delegation between agents.
❌ Proxy Services (Multifactor, Aembit)
Centralized bottleneck. Bearer tokens still vulnerable to session smuggling attacks.
❌ Environment Variables
Insecure plaintext storage. No audit trail. All agents get same access level.
Even If Stolen, Capabilities Can't Be Exploited
Let's replay the Palo Alto attack scenario with capabilities and watch it fail at multiple independent security layers.
Scroll through each defense layer to see how the attack is neutralized at every step.
Defense in Depth: How Attacks Are Stopped
Even if an attacker steals a capability, multiple independent security layers prevent exploitation
capability_token = "Ey6hYWxnI..." // max_uses: 10, interfaces: ["database:read"] Limited-Use Enforcement
Attack Blocked
// Attacker tries to use stolen token repeatedly
for (let i = 0; i < 1000; i++) {
gateway.execute(stolen_token, "query");
}
UsageLimitExceeded - Token exhausted
Cryptographic Signature Verification
Attack Blocked
// Attacker tries to modify max_uses
stolen_token.max_uses = 99999;
gateway.execute(stolen_token, "query");
InvalidSignature No Privilege Escalation
Attack Blocked
// Attacker tries to add write permissions
malicious_cap = stolen_token.derive({
interfaces: ["database:write"] // escalate!
});
AttenuationViolationError Comprehensive Audit Trail
Attack Detected
[10:00:01] ✓ capability_id=cap-123, agent=analysis_001, action=query,
uses=1/10
...
[10:00:10] ✓ capability_id=cap-123, agent=analysis_001, action=query,
uses=10/10
[10:00:11] ❌ capability_id=cap-123, agent=UNKNOWN, action=query,
error=UsageLimitExceeded
Result: Attack Neutralized
Even with a stolen capability, the attacker achieved minimal damage:
- Maximum 10 read operations
- Only "transactions" table accessible
- No write/delete permissions
- 30-minute expiration enforced
- ❌ Unlimited replay attacks
- ❌ Token tampering/forgery
- ❌ Privilege escalation
- ❌ Silent exfiltration
With OAuth Bearer Tokens (No Defense)
The same attack with a stolen OAuth token would result in:
- ✗ Unlimited reuse until token expires (hours/days)
- ✗ Full access to all resources the token permits
- ✗ No usage limits - attacker can make 10,000+ requests
- ✗ Indistinguishable from legitimate use in logs
Protect Your Multi-Agent System
If your agents share credentials using any of these approaches, you're exposed to session smuggling attacks:
We're working with design partners to deploy capability-based credentials for multi-agent systems.