Capability-Based Security for AI Agents

When building multi-agent AI systems, you’ll eventually face a deceptively simple question: “How do I let my orchestrator agent safely share its database credentials with a worker agent—but only for reading, only for 10 minutes, and only for the ‘customers’ table?”

This isn’t an edge case. It’s the fundamental challenge of credential delegation in multi-agent architectures—and current solutions (OAuth, Vault, proxies) weren’t built for it.

Amla’s capability-based credentials solve this: cryptographic tokens that automatically lose permissions as they’re delegated, with built-in expiration, usage limits, and tamper-proof audit trails.

Consider a typical multi-agent workflow:

Scenario: Your document processing orchestrator needs to analyze a PDF:

Orchestrator has full access: read/write to documents, metadata, and analytics tables
Orchestrator spawns Analyzer that needs read access to documents and metadata
Analyzer spawns Text Extractor that only needs read access to documents
Analyzer spawns Metadata Extractor that only needs read access to metadata

The problem: How do you give each agent exactly the access it needs without:

❌ Giving everyone the same all-powerful credentials (security nightmare)
❌ Creating individual database users for every ephemeral agent (impossible to scale)
❌ Routing every request through a central authorization server (latency bottleneck)
❌ Storing secrets in environment variables (leaks to all child processes)

What you need: A way for the orchestrator to create progressively weaker credentials that:

Work offline (no auth server round-trip on every request)
Can’t be escalated (child can’t gain more permissions than parent)
Automatically expire (short TTLs for workers)
Track usage (prevent unlimited replay attacks)
Create audit trails (know exactly who accessed what)

How Capabilities Solve This

Amla capabilities flip the traditional credential model. Instead of bearer tokens that can be copied infinitely, capabilities are cryptographically signed, limited-use credentials that automatically lose permissions at each delegation level.

Key Features

✅ Cryptographic Attenuation - Each child capability has fewer permissions than its parent (enforced by Ed25519 signatures)

✅ No Privilege Escalation - Mathematically impossible for a child to gain more permissions

✅ Built-in Expiration - Every capability has a time-to-live; children expire sooner

✅ Usage Limits - Track and limit how many times a capability can be used

✅ Offline Verification - No central server needed to validate capabilities

✅ Audit Trails - Every action creates a verifiable log entry

✅ Tamper-Proof - Any modification breaks the cryptographic signature

Simple Example

from amla_sdk import AmlaClient

# Create root capability for orchestrator
root = client.create_root_capability(
    interfaces=["database:read", "database:write"],
    resources=["*"],  # All resources
    ttl_seconds=28800  # 8 hours
)

# Create attenuated capability for worker (automatic privilege reduction)
worker = root.attenuate(
    interfaces=["database:read"],  # Read-only (write removed)
    resources=["customers"],  # Only customers table
    ttl_seconds=3600,  # 1 hour (shorter)
    max_uses=100  # Limited uses
)

# Worker CANNOT escalate privileges - cryptographically enforced
# Worker CANNOT write - only has read interface
# Worker CANNOT access other tables - only has customers resource
# Worker expires in 1 hour - cannot extend TTL

Why This Matters

Traditional credentials are ambient authority—they work for any operation the agent can think of. If an agent is compromised (via prompt injection, supply chain attack, etc.), the attacker gets full access.

Capabilities bind authority to specific resources and operations. Even if an agent is compromised, the damage is limited by the capability’s constraints.

Learn More

Ready to implement capabilities in your system? Continue with:

Quickstart Tutorial - Step-by-step guide with code examples
Security Deep Dive - Understanding Confused Deputy attacks and defense mechanisms
Advanced Topics - Use cases, implementation tips, and best practices

Or jump straight to our API documentation to start building.

Getting Started

To start using capabilities in your system:

Request beta access: Email [email protected] for access
Install the SDK: pip install amla-sdk
Set up your gateway: Deploy the Amla gateway (Docker/Kubernetes)
Design your hierarchy: Plan your capability delegation structure
Implement attenuation: Add capability creation to your agent code

Check out our documentation for detailed implementation guides and our GitHub repositories for SDK examples.

The Future of Agent Security

As systems become more autonomous and interconnected, the old model of static credentials and bearer tokens becomes untenable. Capability-based credentials provide a path forward: cryptographically secure, independently verifiable, and infinitely flexible.

At Amla Labs, we’re building this future one delegation at a time. Join us in reimagining how agents prove what they’re allowed to do.

Want to implement capabilities in your agent system? Reach out or check our documentation to get started.

Related Reading: