§ · compare
Where Emberlink fits.
AI agent authority is one job, but it factors into eight sub-questions. Most systems answer two or three. Emberlink composes them and signs the answer.
§1 · the eight questions
Authority is not one question.
When an agent acts, the trust layer has to decide eight separate things. A system that handles only some of them leaves the rest to ambient authority — the failure mode the AI agent era cannot afford.
- 1Did the agent have authority at all? Was there a credential or token that authorized this call?
- 2Who granted it? A specific human, a delegating system, or a policy-as-code rule — and is that issuer cryptographically named?
- 3Was the grant narrowed? Scoped to one repo, one budget, one model, one window — instead of "all my access"?
- 4Could the grant delegate? Can the agent hand a strict subset to a sub-agent without re-asking the human?
- 5Did the child agent inherit authority? When delegation happens, can the child prove its authority chains back to the original grant?
- 6Was the action inside policy? Even with a valid grant, was this specific action allowed by the rules attached to it?
- 7Was authority revoked or expired? Can a human kill the grant in flight, and does it self-expire if the human forgets?
- 8Can the proof be verified outside the vendor's dashboard? When auditors or a third party ask "did this happen?", is there a signed artifact that anyone can check offline?
§2 · the matrix
Eight questions × seven systems.
✓ primitive answer · ~ partial / depends on usage · — not addressed
| authority sub-question | emberlink | HashiCorp Vault | Okta + OIDC | SatGate | UCAN | Biscuit | MCP registry |
|---|---|---|---|---|---|---|---|
| 1. Did the agent have authority? | ✓composite grant gates the call | ✓vault token bearer | ✓access token bearer | ✓gate runs at call time | ✓capability token holder | ✓capability token holder | —discovery, not authorization |
| 2. Who granted it? | ✓named issuer in signed receipt | ~vault server, no human chain | ✓admin assignment in IdP | ~operator policy | ✓issuer DID in token | ✓root key + delegation chain | —no grant model |
| 3. Was the grant narrowed? | ✓composite-scope statements | ~policy templates, coarse | ~OAuth scopes, coarse | ~policy-defined | ✓caveats narrow on delegate | ✓caveats narrow on delegate | —N/A |
| 4. Could the grant delegate? | ✓delegation is a primitive | —tokens don't delegate | ~impersonation, coarse | —no delegation primitive | ✓delegation is the protocol | ✓attenuation is the protocol | —N/A |
| 5. Did the child agent inherit? | ✓attenuated child grant | —flat token model | —no inheritance semantics | —no inheritance primitive | ✓delegation chain proves it | ✓attenuation chain proves it | —N/A |
| 6. Was the action inside policy? | ✓policy engine + grant statements | ~vault policies, coarse | ~scope check at API edge | ✓gate is the policy | ~caveats checked by verifier | ~caveats checked by verifier | —N/A |
| 7. Was authority revoked / expired? | ✓TTL + live revoke | ✓TTL + revoke API | ~TTL; revoke is awkward in flight | ~policy update; no per-grant revoke | ~TTL only — no online revoke | ~TTL only — no online revoke | —N/A |
| 8. Proof verifiable outside vendor dashboard? | ✓signed Receipt, verify offline | —vendor audit log only | —vendor audit log only | —vendor audit log only | ~grant verifies; action does not | ~grant verifies; action does not | —N/A |
Scroll horizontally on small screens. Each cell links a question to a system's primitive — not a marketing claim.
§3 · the fit
Emberlink integrates. It does not replace.
Vault holds the secret. Okta names the human. UCAN and Biscuit carry the delegation chain. MCP registries discover the tools. Emberlink is the layer where all of these become a single signed answer to "did the agent have authority, and did it stay inside it?" — verifiable by anyone, after the fact.
The verifiable-receipt-at-action-time layer is the gap. Emberlink fills it.