262 lines
12 KiB
Markdown
262 lines
12 KiB
Markdown
# ACT (Agent Compact Token) — Medium Blog Post Series
|
|
|
|
## Series Title: "Securing the Agentic Web"
|
|
|
|
Target audience: Backend/platform engineers, AI practitioners, security-minded architects building multi-agent systems.
|
|
|
|
---
|
|
|
|
## Post 1: "Why OAuth Isn't Enough for AI Agents"
|
|
|
|
**Hook**: OAuth was built for humans clicking "Allow." Autonomous agents don't click buttons — they chain tasks, delegate to sub-agents, and need cryptographic proof of what they did, not just what they were allowed to do.
|
|
|
|
**Key points**:
|
|
- OAuth assumes a human in the loop (consent screens, redirect flows)
|
|
- Agents need machine-to-machine auth that works without an Authorization Server
|
|
- The missing piece: **accountability** — OAuth proves authorization, but not execution
|
|
- Agents operate across organizational boundaries; federated trust is essential
|
|
- Existing alternatives and their gaps:
|
|
- **SPIFFE/SPIRE**: Workload identity, but no capability scoping or execution records
|
|
- **ZCAP-LD**: Capability delegation, but JSON-LD complexity and no execution phase
|
|
- **Macaroons**: Contextual caveats, but no standardized structure for agent workflows
|
|
- **OPA/Cedar**: Policy engines, but no portable token format
|
|
|
|
**Diagram idea**: Side-by-side comparison — OAuth flow vs. ACT flow for an agent task
|
|
|
|
**Call to action**: Introduce ACT as "authorization + accountability in a single token"
|
|
|
|
---
|
|
|
|
## Post 2: "One Token, Two Lives — The ACT Lifecycle"
|
|
|
|
**Hook**: What if your authorization token could *grow up* — transforming from a permission slip into a receipt?
|
|
|
|
**Key points**:
|
|
- **Phase 1 — Authorization Mandate**: Signed by the issuing agent
|
|
- "Agent A authorizes Agent B to do X, with these constraints, until time T"
|
|
- JOSE header: `typ: "act+jwt"`, `alg: "EdDSA"`, `kid`
|
|
- Claims: `iss`, `sub`, `aud`, `exp`, `jti` (UUID v4), `task`, `cap`
|
|
- The `task` object: purpose, data sensitivity, created_by
|
|
- The `cap` array: fine-grained actions with constraints
|
|
- **Phase 2 — Execution Record**: Re-signed by the executing agent
|
|
- Same token, new claims added: `exec_act`, `par`, `exec_ts`, `status`
|
|
- Critical: header `kid` switches from issuer's key to executor's key
|
|
- Optional: `inp_hash` and `out_hash` (SHA-256 of actual I/O data)
|
|
- The `err` object for failure cases
|
|
|
|
**Code example**: Show a Phase 1 JWT payload, then the same payload with Phase 2 claims added
|
|
|
|
**Why it matters**: One token = complete audit trail. No separate logging system needed. The token *is* the evidence.
|
|
|
|
**Analogy**: A signed work order (Phase 1) that becomes a signed completion certificate (Phase 2)
|
|
|
|
---
|
|
|
|
## Post 3: "Zero to PKI — ACT's Trust Tier Progression"
|
|
|
|
**Hook**: Most security specs start with "first, set up your PKI infrastructure." ACT starts with "first, share a key over Signal."
|
|
|
|
**Key points**:
|
|
- **Tier 1 — Pre-Shared Keys** (mandatory to implement)
|
|
- Ed25519 key pairs shared out-of-band
|
|
- `kid` is just an opaque string both parties agree on
|
|
- Zero infrastructure. Works on day one. Perfect for prototyping and internal agents
|
|
- Key registry: simple dict mapping `kid → public_key_bytes`
|
|
- **Tier 2 — PKI / X.509**
|
|
- `kid` = SHA-256 thumbprint of DER-encoded certificate
|
|
- `x5c` JOSE header carries the certificate chain
|
|
- Standard X.509 chain validation against trusted CA store
|
|
- For enterprises with existing PKI
|
|
- **Tier 3 — Decentralized Identifiers (DIDs)**
|
|
- `did:key` — self-contained, no resolution needed (Ed25519 public key in the DID itself)
|
|
- `did:web` — HTTP-resolvable, cacheable with TTL
|
|
- For cross-organizational federation without shared CA
|
|
|
|
**Diagram idea**: Three-rung ladder — each tier adds infrastructure but also adds trust guarantees
|
|
|
|
**Why it matters**: You can start using ACT in 10 minutes with pre-shared keys, then upgrade to PKI or DIDs as your deployment matures. No rip-and-replace.
|
|
|
|
---
|
|
|
|
## Post 4: "Delegation Without Escalation — How ACT Prevents Rogue Sub-Agents"
|
|
|
|
**Hook**: When Agent A delegates to Agent B who delegates to Agent C... how do you ensure C can't do more than A originally allowed?
|
|
|
|
**Key points**:
|
|
- The `del` claim: `{ depth, max_depth, chain[] }`
|
|
- `chain` is ordered root → immediate parent
|
|
- Each entry: `{ delegator, jti, sig }`
|
|
- **Capability attenuation**: child's `cap` MUST be a subset of parent's `cap`
|
|
- Constraints can only get MORE restrictive, never less
|
|
- Example: parent allows `data.read` with `max_rows: 1000` → child can set `max_rows: 100` but not `max_rows: 5000`
|
|
- **Chain verification**:
|
|
- `sig = Sign(delegator.private_key, SHA-256(parent_act_compact_bytes))`
|
|
- Each chain entry verified against delegator's public key
|
|
- **Rejection conditions** (5 ways delegation fails):
|
|
1. `depth > max_depth`
|
|
2. `chain.length != depth`
|
|
3. Any chain signature fails
|
|
4. `cap` contains actions not in parent's `cap`
|
|
5. Any constraint is less restrictive than parent's
|
|
|
|
**Code example**: Three-agent delegation chain with progressively narrower capabilities
|
|
|
|
**Analogy**: Power of attorney — you can give someone authority to act on your behalf, and they can sub-delegate, but each level can only narrow the scope, never widen it
|
|
|
|
---
|
|
|
|
## Post 5: "Following the Thread — DAG-Based Execution Tracking"
|
|
|
|
**Hook**: In a world where agents spawn agents that spawn agents, how do you answer "what happened and in what order?"
|
|
|
|
**Key points**:
|
|
- Every Phase 2 ACT has a `par` (parents) array — JTIs of predecessor tasks
|
|
- `[]` for root tasks (no parents)
|
|
- Multiple parents = fan-in (joining parallel branches)
|
|
- The `jti` itself serves as the task ID
|
|
- **DAG validation rules**:
|
|
1. `jti` uniqueness within `wid` (workflow) scope
|
|
2. Every parent `jti` must exist as a verified Phase 2 ACT in the ledger
|
|
3. Temporal ordering: `parent.exec_ts < child.exec_ts + 30s` (clock skew tolerance)
|
|
4. Acyclicity: max 10,000-node traversal limit
|
|
5. `exec_act` must match one of the `cap[].action` values
|
|
- **Workflow grouping**: Optional `wid` (workflow ID) groups related ACTs
|
|
|
|
**Diagram idea**: A DAG of 6-8 tasks showing fan-out (parallel dispatch) and fan-in (result aggregation)
|
|
|
|
**Real-world example**: ML pipeline — data fetch → preprocess (fan-out to 3 shards) → train (fan-in) → evaluate → deploy
|
|
|
|
**Why it matters**: Compliance, debugging, incident response. "Show me every action taken in workflow X, in causal order, with cryptographic proof."
|
|
|
|
---
|
|
|
|
## Post 6: "Humans in the Loop — ACT's Oversight Mechanism"
|
|
|
|
**Hook**: Full autonomy is terrifying. Full control is impractical. ACT's oversight mechanism is the middle ground.
|
|
|
|
**Key points**:
|
|
- The `oversight` claim:
|
|
- `requires_approval_for`: array of action strings that need human sign-off
|
|
- `approval_ref`: reference to the approval record
|
|
- How it works in practice:
|
|
- Agent receives mandate with `oversight.requires_approval_for: ["data.delete"]`
|
|
- Before executing `data.delete`, agent must obtain approval
|
|
- Approval reference stored in `oversight.approval_ref`
|
|
- Selective oversight: Only specific high-risk actions require approval, not everything
|
|
- Composable with delegation: oversight requirements propagate down the chain
|
|
|
|
**Why it matters**: Regulatory compliance (GDPR right-to-delete, financial transactions), enterprise risk management, building trust in agent systems incrementally
|
|
|
|
---
|
|
|
|
## Post 7: "Threat Model Deep Dive — What ACT Defends Against"
|
|
|
|
**Hook**: Every security spec claims to be secure. Here's exactly what ACT protects against — and what it doesn't.
|
|
|
|
**Key points**:
|
|
- **Defended threats**:
|
|
- Token forgery (Ed25519 signatures, no symmetric algs, no "alg: none")
|
|
- Privilege escalation (capability attenuation in delegation chains)
|
|
- Replay attacks (jti uniqueness, exp enforcement, clock skew tolerance ≤300s)
|
|
- Execution fabrication (Phase 2 re-signature by sub's key, not iss's key)
|
|
- Audit trail tampering (hash-chained append-only ledger)
|
|
- Man-in-the-middle on delegation (chain signatures bind to parent token bytes)
|
|
- **Security constraints in implementation**:
|
|
- Algorithm allowlist: EdDSA (Ed25519), ES256 only. No HS*, no "none"
|
|
- Key material zeroed on deletion
|
|
- iat must not be unreasonably future (≤30s)
|
|
- aud verification mandatory
|
|
- **Out of scope** (honest about limitations):
|
|
- Token revocation (not in v00 — mentioned as future work)
|
|
- Confidentiality of token contents (JWS, not JWE)
|
|
- Compromised agent keys (standard key management applies)
|
|
|
|
**Table**: Threat → ACT mitigation → Residual risk
|
|
|
|
---
|
|
|
|
## Post 8: "ACT Meets the IETF — Why Standardization Matters for Agent Interop"
|
|
|
|
**Hook**: Your agents and my agents need to talk. Without a standard, we're back to building custom integrations for every partner.
|
|
|
|
**Key points**:
|
|
- The IETF process: Internet-Draft → RFC pathway
|
|
- `draft-nennemann-act-00` is the first submission
|
|
- Building on existing standards: RFC 7519 (JWT), RFC 7515 (JWS), RFC 7518 (JWA)
|
|
- ABNF notation for action names, formal CDDL-style structures
|
|
- Why an IETF RFC vs. a blog post or GitHub repo:
|
|
- Interoperability testing with multiple implementations
|
|
- Formal security review
|
|
- Stable reference for contracts and regulations
|
|
- Media type registration: `application/act+jwt`
|
|
- **Interoperability requirements**:
|
|
- MUST implement Tier 1 (pre-shared keys)
|
|
- MUST support EdDSA (Ed25519)
|
|
- MUST verify delegation chains
|
|
- MUST enforce DAG validation
|
|
- Comparison with other agent-related standards efforts
|
|
|
|
**Why it matters**: As AI agents become infrastructure, we need the same rigor we applied to HTTP, TLS, and OAuth
|
|
|
|
---
|
|
|
|
## Post 9: "Building Your First ACT Agent — A Hands-On Tutorial"
|
|
|
|
**Hook**: Enough theory. Let's build two agents that authorize, execute, and audit a task using ACT.
|
|
|
|
**Key points** (step-by-step tutorial):
|
|
1. Install the `act` Python package
|
|
2. Generate Ed25519 key pairs for two agents
|
|
3. Create a Phase 1 mandate (Agent A → Agent B: "read customer data")
|
|
4. Agent B validates the mandate
|
|
5. Agent B executes and creates Phase 2 record (with inp_hash/out_hash)
|
|
6. Append to audit ledger
|
|
7. Verify the complete chain
|
|
8. Add delegation: Agent B delegates subset to Agent C
|
|
9. Verify Agent C's execution in the DAG
|
|
|
|
**Code examples**: Complete working Python code for each step, using the reference implementation
|
|
|
|
**Real-world scenario**: E-commerce — order service authorizes inventory agent to check stock, inventory agent delegates to warehouse-specific sub-agents
|
|
|
|
---
|
|
|
|
## Post 10: "The Road Ahead — ACT's Evolution and the Agentic Future"
|
|
|
|
**Hook**: ACT v00 is a foundation. Here's what's coming and how you can shape it.
|
|
|
|
**Key points**:
|
|
- **Future work mentioned in the draft**:
|
|
- Token revocation mechanisms
|
|
- Formal capability algebra (lattice-based constraint reasoning)
|
|
- Performance benchmarks across implementations
|
|
- Integration patterns with existing auth infrastructure
|
|
- Privacy-preserving execution records (selective disclosure)
|
|
- **Community and contribution**:
|
|
- Reference implementation as the interoperability baseline
|
|
- Test vectors (Appendix B) as the conformance suite
|
|
- How to write a second implementation (in Rust, Go, etc.)
|
|
- **The bigger picture**:
|
|
- Agent-to-agent economy needs trust primitives
|
|
- ACT as one layer in the agentic stack
|
|
- Composability with other standards (OpenID for agents, SCIM, etc.)
|
|
|
|
---
|
|
|
|
## Cross-Series Themes
|
|
|
|
1. **Progressive complexity**: Each post builds on the previous, but each can stand alone
|
|
2. **Code-first**: Every concept illustrated with real Python snippets from the reference implementation
|
|
3. **Honest trade-offs**: Acknowledge what ACT doesn't solve (yet)
|
|
4. **Standards matter**: Thread the IETF standardization story throughout
|
|
5. **Real-world grounding**: Each post connects to concrete use cases
|
|
|
|
## Publication Strategy
|
|
|
|
- **Cadence**: 1 post per week, 10-week series
|
|
- **Length**: 1,500-2,500 words per post (8-12 min read)
|
|
- **Tags**: AI, Security, Authentication, Distributed Systems, IETF
|
|
- **Series landing page**: Link all posts, provide a "start here" guide
|
|
- **Code repo**: Link to the reference implementation throughout
|
|
- **Post 9** can be published on dev.to / Hashnode in addition to Medium for developer reach
|