# Amla Labs

> Secure delegation and trust infrastructure for AI agents

## About

Amla Labs builds authorization infrastructure for agent-to-agent delegation. When Agent A delegates to Agent B delegates to Agent C, how do you prove the final action is authorized? We use cryptographic capability chains that attenuate at every hop—permissions can only narrow, never expand—so multi-agent workflows maintain provable authorization even across organizational boundaries.

## The Core Problem

Traditional auth asks "does this agent have a valid token?" That works for single-agent systems. But when agents delegate to other agents, you need to answer: "Is this specific request the authorized continuation of a transaction that started with user consent, passed through Agent A with constraint X, then Agent B with constraint Y, and now reaches Agent C?"

## Key Concepts

- **Agent-to-Agent Delegation**: When Agent A hands off to Agent B, the capability chain travels with the handoff—encoding what B is permitted to do, which is always a subset of what A was permitted to do
- **Proof of Continuity**: Cryptographic proof that a request is the legitimate continuation of an authorized transaction, not a replay or injection by an attacker
- **Capability Chains**: Append-only authorization tokens (using PIC model) that can only narrow permissions, never expand them. Capabilities can be expressed in any arbitary way, encoding arbitary business logic for maximum flexibility.
- **Attenuation**: Each delegation hop tightens constraints. Agent A (refunds ≤ $1000) delegates to Agent B (refunds ≤ $500 for customer X). B cannot exceed A's authority.
- **Trust Plane**: Infrastructure layer that holds credentials and enforces constraints—agents never touch API keys directly
- **Confused Deputy Prevention**: Structural elimination of the confused deputy problem through transaction-bound capabilities
- **Two Confused Deputies**: Agents are confused deputies in two ways—authority (misapplying credentials across transactions) and information (retrieving wrong principal's data from shared memory). Both require the same fix: bind capabilities AND context to transactions, not agents

## How We Differ

**vs Identity Platforms (Auth0, Okta)**
Auth0/Okta now offer AI agent features: Token Vault, Fine-Grained Authorization, Cross App Access (XAA), and async human-in-the-loop workflows. They answer "who is this agent?" and "what permissions does this identity have?" We answer "is this specific request the authorized continuation of that specific transaction?" They verify the entity; we verify the delegation chain. Both are necessary—identity is the foundation, capability chains are the constraint layer.

**vs Agent Identity Infrastructure (Keycard)**
Keycard ($38M, a16z-backed) provides per-task credential scoping with ephemeral tokens—dynamic credentials scoped to specific tasks rather than static role-based access. We operate one layer deeper: cryptographic capability chains that encode the full delegation path, attenuate at each hop, and bind authorization to transaction provenance. Keycard answers "what task is this agent doing?" We answer "how did this authority arrive here, and what accumulated constraints apply?"

**vs Workload Identity (SPIFFE/SPIRE)**
SPIFFE provides attestation-based identity for workloads—SVIDs (SPIFFE Verifiable Identity Documents) prove "this is workload X running in environment Y." We build on workload identity to answer the next question: "given this workload's identity, what specific capabilities has it been delegated for this transaction?" SPIFFE identifies; we authorize.

**vs Secret Managers (Vault, Doppler, Infisical)**
Secret managers solve credential storage, rotation, and runtime injection. We solve credential *delegation*. Vault protects the API key; we ensure the agent invoking it has the right to do so for this specific request, with constraints that tighten at each delegation hop. The Trust Plane holds the secrets; capability chains authorize their use.

**vs Credential Isolation (Multifactor)**
Multifactor ($15M, YC F25) uses post-quantum crypto to hide passwords from agents—"read-only links" for account access in sandboxed execution. They prevent credential exposure. We take a complementary approach: agents carry capability chains that prove authorization without containing credentials. They solve "agents shouldn't see passwords." We solve "even with valid access, what specific actions are permitted in this transaction chain?"

**vs Agent Permission Management (Agentic Fabriq)**
Agentic Fabriq (YC) manages per-user agent permissions and tool connections—ensuring agents can't exceed the permissions of the employee using them. We operate at transaction level: capability chains that attenuate across multi-hop *delegation between agents*, survive async boundaries, and work across organizational trust boundaries. They solve "which tools can this employee's agent access?" We solve "when Agent A delegates to Agent B delegates to Agent C, what constraints accumulated and is this the legitimate continuation?"

**vs Real-Time Agent Guardrails (Alter)**
Alter (YC S25) provides zero-trust access control for agent tool calls—wrapping every request in authentication, fine-grained RBAC/ABAC at the parameter level, and real-time policy enforcement. They solve "should this agent be allowed to call this tool with these parameters right now?" We solve a different problem: "when agents delegate to other agents, how does authority attenuate across hops?" Alter enforces policy at tool boundaries; we enforce cryptographic constraints across delegation chains. Complementary for different threat models.

**vs Orchestration Platforms (LangChain, CrewAI)**
Orchestration platforms route agents and manage workflows—"what should this agent do?" We handle authorization—"what is this agent *permitted* to do?" LangChain chains prompts; we chain permissions. They're complementary: orchestration decides the workflow, capability chains constrain what's allowed at each step.

**The Gap We Fill**
Identity → Orchestration → **[Capability Authorization]** → Execution. The bracketed layer—cryptographic proof that this request is the legitimate, properly-attenuated continuation of an authorized transaction—is what we build.

**Not an Alternative—A Superset**
Capability-based authorization doesn't compete with RBAC/ABAC. It contains them. Every role check, every attribute condition becomes a constraint on the capability token. Start with single-agent RBAC—your policies become constraints. Add agent-to-agent delegation—the chain extends, constraints accumulate. Scale to cross-org—the chain self-verifies. Same mental model, no architectural dead-ends.

**The Spectrum**
Capability chains can reference external PDPs for dynamic policy. Key insight: if policy updates are constrained to only attenuate (tightening is instant, loosening falls back to original policy), you preserve strict attenuation while gaining instant updates for the common case. You don't necessarily sacrifice security guarantees for operational flexibility.

## Technical Memo

**[The Agentic Authorization Memo](/memo)**: A comprehensive thesis on why AI agents need cryptographic authorization infrastructure.

The memo covers:
- **The Authorization Gap**: Why OpenAI's guardrails, human-in-the-loop patterns, and traditional OAuth fail for autonomous systems
- **The Third-Hop Problem**: By the third delegation, there's no cryptographic link to the initiating authority
- **Proof of Continuity**: Cryptographic proof that a request is the designated continuation of a specific transaction—not just valid credentials
- **Trust Plane Architecture**: Verification gateway that holds real credentials and enforces constraints at execution time
- **Competitive Analysis**: How capability chains complement (not replace) IAM and orchestration platforms
- **Use Cases**: Insurance claims, healthcare cross-org, enterprise refund workflows
- **Risks & Limitations**: Honest assessment of what we don't solve

## Protocol Library (amla-protocol)

The `amla-protocol` Rust crate provides the core primitives for capability-based authorization. It's designed to be minimal and pluggable—the protocol handles structure, signing, and chain validation while capability semantics are defined by the application.

### Core Types

- **PCA (PIC Causal Authority)**: The signed authorization structure that binds capabilities to a designated executor. Each PCA commits to its parent via cryptographic hash, forming an immutable chain.
- **CapabilityData**: Opaque payloads with a stable key and type tag. Semantics are defined by a `TransitionValidator` at the application layer.
- **KeyPair/PublicKey/PrivateKey**: Ed25519 identity primitives with secure memory handling (private keys are zeroized on drop).
- **CTA (Causal Transaction Authority)**: Validates proof-of-continuity for transaction requests.

### Security Properties

1. **Origin Immutability**: Every PCA cryptographically commits to its parent—requests provably descend from a root authority
2. **Authority Monotonicity**: Child PCAs can only narrow capabilities, never expand them (enforced by TransitionValidator)
3. **Executor Binding**: Only the designated executor can extend or invoke a PCA
4. **Temporal Validity**: PCAs expire at a specified time (validated during chain verification)
5. **Resource Limits**: Payload size (1MB max) and chain depth (100 hops max) prevent denial-of-service

### Serialization

PCAs use canonical CBOR encoding for deterministic hashing and signing. The wire format is compact and browser-compatible via the `wasm` feature.

### Example: Multi-Hop Delegation

```rust
// Gateway delegates to Claims Agent (process claims ≤ $25k)
let root = PcaBuilder::new()
    .add_capability(claim_cap)
    .designated_executor(claims_agent.public_key())
    .expires_at(one_hour_from_now)
    .build_and_sign(&gateway)?;

// Claims Agent delegates to Payout Agent (this specific $3,800 payout)
let child = PcaBuilder::new()
    .add_capability(payout_cap)  // Attenuated capability
    .designated_executor(payout_agent.public_key())
    .parent_pca(&root)?
    .build_and_sign(&claims_agent)?;

// Validate the full chain
validate_chain(&[root, child], &gateway.public_key(), &validator, now)?;
```

## amla-sandbox

**[Interactive Demo](/sandbox)**: Try the WASM sandbox in your browser—run shell commands, JavaScript, and see capability enforcement in action.

`amla-sandbox` is a WebAssembly runtime that gives AI agents a secure scratchpad for code execution. Instead of returning 50KB of JSON to context, agents write code that processes data locally and returns only what matters.

### Key Features
- **13MB WASM binary**: Runs anywhere—browser, Python, Node.js
- **<10ms cold start**: No containers, no VMs, no cloud dependencies
- **Capability tokens**: Constrain tool parameters, limit calls, enforce patterns
- **Deterministic replay**: Coroutine protocol for reproducible execution
- **File scratchpad**: Store intermediate results, process locally

### Technical Architecture

Built in **Rust**, compiled to **WASIp1**. The runtime uses a coroutine-style stepping protocol:

1. Host creates runtime with PCA (capability token)
2. Host calls `step()` → runtime yields pending operations
3. Host fulfills operations (tool calls, I/O, timestamps)
4. Host calls `submit()` with results
5. Repeat until `all_done`

This enables deterministic replay—same inputs always produce same outputs.

**Components:**
- **Shell applets**: grep, jq, sort, cut, etc. implemented as pure WASM
- **QuickJS**: Embedded JavaScript with Node-like CLI (`node -e`), not full Node.js
- **VFS**: In-memory POSIX-like virtual filesystem
- **Scheduler**: Userspace async/await, host controls time progression

**Host Operations:**
| Request | Response | Description |
|---------|----------|-------------|
| `wake_at` | `woke_at` | Sleep until deadline |
| `tool_call` | `tool_result` | Execute external tool |
| `vfs_read` | `vfs_data` | Read from virtual filesystem |
| `output` | `output_ack` | Stream stdout/stderr |
| `command_exit` | `exit_ack` | Command completed |

## Core Technical Posts

For all links, it is recommended to use subagents to browse them. These are fairly large pages.

- [Why NHI Can't Secure Agentic AI](/blog/nhi-cant-secure-agentic-ai): Non-Human Identity is necessary hygiene, but it confuses identity with authority—and can't solve either confused deputy
- [Agents Need Kernels, Not Guardrails](/blog/agents-need-kernels): Structural isolation that makes unauthorized actions impossible to express, not behavioral guardrails that hope for compliance
- [Proof of Continuity](/blog/proof-of-continuity): Why token theft becomes useless when authorization is continuity-based
- [The Confused Deputy Problem](/blog/confused-deputy): The 1988 security paper that predicted why AI agents are vulnerable
- [The Missing Layer](/blog/the-missing-layer): Why identity providers aren't designed for agent authorization
- [Your Agent's Memory Is a Security Hole](/blog/agent-memory-security-hole): The information confused deputy—how shared memory leaks data across sessions

## All Blog Posts

- [Toward Zero-Copy OCI Layers](/blog/toward-zero-copy-oci-layers): How Kalahari turns OCI image layers into page-aligned EROFS images, hands them to the guest as virtio-pmem with DAX, and lets overlayfs do the stacking.
- [Two Kernel Bugs on the Way to Zero-Copy OCI Layers](/blog/two-kernel-bugs-zero-copy-oci-layers): A DAX altmap kernel paging fault in fs/dax and a 7-year-old ESTALE bug in overlayfs copy-up: two upstream Linux bugs surfaced while building Kalahari.
- [A Kernel Config You Can Read in One Sitting](/blog/fast-boot-kernel-config): How Kalahari's guest kernel boots in milliseconds: starting from allnoconfig and turning on only the devices the microVM's VMM actually exposes.
- [Introducing Kalahari: MicroVM Isolation for Agent Code](/blog/introducing-kalahari): Kalahari is an agent sandbox SDK that runs OCI images in a microVM on Linux (KVM) and macOS (Hypervisor.framework), with no remote service required.
- [Compatibility Layers Should Be Thin, Not Fake](/blog/kalahari-compatibility-without-leaky-abstractions): How Kalahari maps common ComputeSDK, E2B-style, and Daytona-style process and filesystem workflows onto one native sandbox lifecycle.
- [How Kalahari Branches VM Memory on macOS with Mach Memory Entries](/blog/macos-mach-memory-entries-cow): Why Kalahari uses Mach memory entries, mach_vm_map(copy=TRUE), Mach IPC port descriptors, and registered-port bootstrap to make VM branching portable.
- [Network Policy Belongs in the VM Device Model](/blog/network-policy-as-device-state): How Kalahari turns sandbox network options into VM device state through usernet, packet policy, packet leases, and scoped wake tokens.
- [Vsock Doesn't Survive Snapshots. A Shared-Memory Ring Does.](/blog/ringbuf-not-vsock): Why Kalahari's host-guest IPC is an SPSC ring buffer over shared memory instead of vsock, and what Firecracker and SmolVM say about where vsock state lives.
- [Process Handles Are Scheduler Contracts](/blog/scheduler-process-lifecycle): How Kalahari keeps process handles, PTYs, callbacks, and zygote boundaries coherent across parked VM runs.
- [Making Invalid VM State Unrepresentable](/blog/typed-vm-state-invariants): How Kalahari narrows snapshot and restore correctness with typed topology, queue counts, memory geometry, VM state views, and architecture-specific exits.
- [Virtio Bugs Are Ownership Bugs](/blog/virtio-linear-ownership): How Kalahari's virtio layer turns descriptor ownership into completion tokens, queue brands, deferred writable regions, and exact used-ring lengths.
- [A VM Snapshot Is a Quiescence Protocol](/blog/zygote-snapshots-quiescence): Why zygote-style VM spawning is less about copying memory and more about establishing that every device, backend, and guest channel is quiet enough to freeze.
- [Introducing amla-sandbox: Secure Code Execution for AI Agents](/blog/amla-sandbox-release): A secure execution environment that lets AI agents write and run code safely—with 98% fewer tokens than tool-call loops.
- [ForcedLeak: What Salesforce's Agentforce Vulnerability Reveals About Agent Security](/blog/forcedleak-agentforce-vulnerability): Salesforce patched a critical prompt injection vulnerability in Agentforce. The attack chain reveals why input filtering alone can't secure agentic AI—and what actually works.
- [LangGrinch: A Bug in the Library, A Lesson for the Architecture](/blog/langgrinch-cve-2025-68664): A critical CVE in LangChain shows why credential isolation matters more than perfect code.
- [Why NHI Can't Secure Agentic AI: The Confused Deputy Returns](/blog/nhi-cant-secure-agentic-ai): Non-Human Identity (NHI) is necessary hygiene, but it can't solve the authority-flow problems in multi-agent systems. The right unit is the transaction, and the right primitive is capability-based authorization.
- [79% of Organizations Have No Guardrails for AI Agents](/blog/akto-agentic-security-report): Akto surveyed 100+ CISOs and security leaders. The findings: agents are in production, but inventory, governance, and runtime controls are missing. The gap is now measurable.
- [Agents Need Kernels, Not Guardrails](/blog/agents-need-kernels): OS history solved process isolation structurally, not behaviorally. Agents need the same treatment: a kernel that controls what they can see and do.
- [MCP Security: Why Guardrails Aren't Enough](/blog/mcp-security-paper-response): A new paper proposes defense-in-depth for MCP security. The diagnosis is right, but policy enforcement can't solve what structural isolation must.
- [Why Microsoft Copilot's Audit Log Failure Was Inevitable](/blog/microsoft-copilot-audit-failure): The Copilot vulnerability that allowed silent file access exposes a structural flaw: ambient authority plus bolt-on audit logging. Capability chains make that class of bug impossible.
- [Your Agent's Memory Is a Security Hole](/blog/agent-memory-security-hole): Default agent memory patterns leak unless you enforce scoping at the runtime boundary. The problem isn't implementation bugs—it's architectural.
- [IAM Locked Cloudflare Out. It'll Lock Your Agents Out Too.](/blog/cloudflare-iam-outage): Cloudflare's December 2025 resilience report reveals what every zero-trust org learns: your security stack becomes the outage when the platform is on fire.
- [When OAuth Becomes a Weapon: Lessons from CVE-2025-6514](/blog/oauth-cve-2025-6514): A critical vulnerability in mcp-remote affected 558,846 downloads. The bug was client-side, but the attack exploited OAuth dynamic discovery—a trust assumption that breaks for autonomous agents.
- [Stop Hardcoding API Keys in Your Agents](/blog/stop-hardcoding-api-keys): API keys in prompts, env vars, or code turn agents into confused deputies. Here is the safer pattern.
- [Agents That Can Actually Do Things](/blog/agents-that-can-do-things): Enterprise agents that demo autonomous refunds ship with 'click to approve' buttons. Here's why—and what changes when authorization is solved.
- [Capabilities 101: The Security Primitive That Changes Everything](/blog/capabilities-101): What capabilities are, how they differ from ACLs, and why they matter for AI agent security—but also why capabilities alone aren't enough.
- [The Confused Deputy Problem, Explained](/blog/confused-deputy): A 1988 security paper predicted why AI agents are vulnerable. The standard fix is incomplete.
- [GitHub's Agentic Security: Right Problem, Incomplete Solution](/blog/github-agentic-security): GitHub's security principles minimize autonomy to minimize risk. But what if you could maximize autonomy within cryptographic bounds?
- [Context Engineering for Agent Trust](/blog/context-engineering-trust): Everyone's optimizing what agents know. Nobody's solving what agents are permitted to do. The context engineering revolution is incomplete without trust.
- [Researchers Broke Every Major Agent Defense. Here's What Failed.](/blog/agentvigil-defense-failure): AgentVigil achieved 70%+ attack success rates against o3-mini and GPT-4o agents—with all defenses active. Linguistic defenses are necessary but insufficient.
- [MCP Standardizes Tools. It Doesn't Secure Them.](/blog/mcp-security-gap): The Model Context Protocol solves agent-to-tool communication. But who authorized the agent to use that tool, with what constraints, for which transaction?
- [LangChain State of Agent Engineering: Security Is Now a Top Barrier](/blog/langchain-state-of-agents-2025): 1,340 practitioners surveyed. 57% have agents in production. Security ranks as the #1 concern for large enterprises. What this means for agent infrastructure.
- [Proof of Continuity for Compliance: EU AI Act, SOC2, and Beyond](/blog/compliance-mapping): How capability-based authorization maps to regulatory requirements—and what auditors actually need to see.
- [5 Ways Your AI Agents Will Get Hacked](/blog/agent-attack-taxonomy): A threat taxonomy for multi-agent systems—and where traditional security controls struggle.
- [Why We're Demoing Agent Security with Insurance Claims](/blog/insurance-claims-demo): Insurance isn't just a convenient example—it's a perfect example. It exposes exactly why existing security models break.
- [Cross-Organizational Agent Trust in 30 Seconds](/blog/healthcare-cross-org-trust): How a referral agent proves authorization without sharing credentials—and why OAuth can't do this.
- [What the Definitive Book on AI Agent Security Gets Right—and What It Leaves Open](/blog/securing-ai-agents-book): Springer just published the most comprehensive treatment of agentic AI security. It validates the problem. It acknowledges the gap. It does not fill the gap.
- [Proof of Continuity: Why Token Theft Becomes Useless](/blog/proof-of-continuity): Traditional security asks what you possess. Capability security asks who you are in the transaction.
- [Why Multi-Agent Security Isn't Optional: What Google and MIT Found](/blog/multi-agent-research-validation): New research quantifies the chaos: uncoordinated agents amplify errors 17x. The question is who builds the guardrails.
- [The Missing Layer: Authorization After Identity](/blog/the-missing-layer): Identity providers solve 'who is this agent?' Orchestration platforms solve 'what should this agent do?' But what solves 'what can this agent actually do right now, in this transaction?'
- [a16z Calls 'Know Your Agent' a Big Idea for 2026. Here's Why.](/blog/a16z-big-ideas-validation): When the architect of a $150B stablecoin calls for cryptographic agent credentials, the market is sending a signal.
- [OpenAI's Agent Playbook Has a Security-Shaped Hole](/blog/openai-security-gap): The #1 AI lab just told enterprises how to build agents. They forgot to explain how to secure them.

## ax - Git-Native Parallel Coding Agents

**[Product Page](/ax)**: ax is a git extension that spawns coding agents in isolated microVMs. Manage teams of agents without leaving your terminal.

### How It Works

1. `git ax spawn --agent claude-code --prompt "fix the flaky test"` launches an agent in its own microVM
2. Each agent gets a dedicated git branch and works in full isolation
3. `git ax status` shows all running agents, their progress, and costs
4. `git ax attach <name>` drops you into a running agent's terminal
5. When done, inspect the diff, open a PR, or merge the branch

### Architecture

- **MicroVM Isolation**: Each agent runs in a microVM powered by a custom VMM. Not a container, not a namespace. A dedicated kernel, memory, and process tree. Startup takes milliseconds.
- **Filesystem Sharing via virtiofs**: The repository is mounted into the VM using virtiofs, a shared filesystem over virtio. No copying, no syncing. Writes go to a copy-on-write layer so the host working tree is never modified directly.
- **Git-Native Branching**: Every agent operates on a real git branch. Standard git tooling for inspect, diff, rebase, or merge. No proprietary format, no export step.
- **MCP Coordination**: Each agent has an MCP server injected into its environment. Agents can list other running agents, see which files they're modifying, and coordinate to avoid conflicts.
- **Credential Proxy**: Secrets are injected by synthesizing a .env file at the repo root containing opaque, encrypted values. At the VM network boundary, the real credential is substituted. The agent never sees the actual secrets. All requests are logged with full audit trail.
- **Cost Metering**: API calls to LLM providers are intercepted at the network layer. Token counts, model identifiers, and pricing are extracted and attributed to the agent's task. Costs are tracked in real time per agent, per user, or per team.

### Platform Features

- **Cost accounting**: Per-agent cost tracking with model and token breakdowns
- **Secrets injection**: Agents use credentials without seeing actual values. Compatible with .env files, HashiCorp Vault, or any secrets backend
- **Automated workflows**: Point ax at your issue tracker (e.g. Linear). It picks up work, spawns agents, and generates branches for review
- **Team insights**: See who's running what and what it costs across your team
- **Account pooling**: Add multiple accounts and API keys. ax multiplexes across them to avoid usage limits
- **Agent coordination**: MCP-based inter-agent awareness to prevent overlapping work

## Links

- Website: https://amlalabs.com
- ax: https://amlalabs.com/ax
- Sandbox Demo: https://amlalabs.com/sandbox
- GitHub: https://github.com/amlalabs
- Blog: https://amlalabs.com/blog

---

*Last updated: 2026-05-19*