RFC: Authorization layer for A2A AgentSkill invocations — capability token enforcement at skill boundaries

## Problem statement

A2A's `SecurityRequirement` field in the AgentCard spec provides an extensibility hook for authentication schemes — but there is no standard enforcement mechanism for **authorization at the AgentSkill boundary**. Specifically:

- A calling agent can authenticate successfully (OAuth bearer, API key, mTLS) and then invoke **any** skill the AgentCard advertises
- There is no standard way for an agent server to express *which callers may invoke which skills* with *which parameters*
- For irreversible skills (financial transfers, physical actuation, infrastructure changes), there is no tier-based approval flow — the skill either executes or it doesn't

This is a gap that grows more important as A2A deployments move from demo-grade to production multi-tenant environments.

---

## SINT Protocol as a complementary authorization layer

[SINT Protocol](https://github.com/sint-ai/sint-protocol) is an open-source capability-token enforcement layer designed for agentic tool calls. It is **not** a replacement for A2A's transport security — it operates one layer up, at the skill invocation boundary.

The core primitive is an **Ed25519 capability token** that encodes:
- `subject` — the agent identity that holds this capability
- `resource` — the skill/tool being authorized (`a2a://agent.example.com/skills/transfer_funds`)
- `actions` — permitted actions (`["invoke"]`)
- `tier` — T0 (observe) / T1 (read) / T2 (act) / T3 (commit/irreversible)
- `constraints` — parameter-level restrictions (`max_amount: 1000`, `currency: ["USD"]`)
- `exp` — expiry

Tiers route calls through different approval flows:
- **T0/T1** — auto-execute (low risk, read-only)
- **T2** — operator approval (consequential actions)
- **T3** — human sign-off before execution (irreversible: financial, physical, infrastructure)

---

## How this complements A2A (not replaces)

```
Caller Agent
│
│ A2A Task (authenticated via SecurityRequirement: OAuth/mTLS)
▼
Agent Server
│
│ PolicyGateway checks: does this caller hold a valid capability
│ token for this AgentSkill at this tier?
▼
AgentSkill.execute()
```

A2A handles *who is calling*. SINT handles *what are they allowed to do*.

---

## 10-line integration sketch

```typescript
import { PolicyGateway } from "@sint/gate-policy-gateway";

const gateway = new PolicyGateway({
rules: [
{ resource: "a2a://*/skills/transfer_funds", actions: ["invoke"], tier: "T3_commit" },
{ resource: "a2a://*/skills/read_balance", actions: ["invoke"], tier: "T0_observe" },
{ resource: "a2a://*/skills/send_message", actions: ["invoke"], tier: "T2_act" },
],
});

// In your A2A task handler:
app.post("/tasks/send", async (req, res) => {
const token = extractCapabilityToken(req.headers); // from A2A metadata
await gateway.enforce(req.body.skill, token); // throws if unauthorized
const result = await agentSkills[req.body.skill].execute(req.body.params);
res.json(result);
});
```

---

## T0–T3 mapping to AgentSkill risk classes

| Tier | A2A skill examples | Approval flow |
|------|-------------------|---------------|
| T0 observe | `search_knowledge_base`, `get_status` | Auto-execute |
| T1 read | `read_document`, `list_agents` | Auto-execute |
| T2 act | `send_notification`, `update_record` | Operator approval |
| T3 commit | `transfer_funds`, `deploy_code`, `control_actuator` | Human sign-off |

---

## Questions for the community

1. Is this the right layer to address in the A2A spec, or is this explicitly out of scope (left to deployers)?
2. Would a `capabilityToken` field in A2A task metadata be a reasonable extension point, or is there a better hook?
3. Is there interest in a formal `AuthorizationScheme` type in the AgentCard `SecurityRequirement` to express capability-token-based enforcement?

SINT Protocol: https://github.com/sint-ai/sint-protocol (Apache 2.0, 1,105 tests, 31 packages)

Happy to collaborate on a spec draft if there's interest.