APS as cryptographic enforcement layer for IBAC intent evaluation
The IBAC architecture describes: Intent parser → Policy mapper → Authorization engine → Tool gateway. This is the right model. The gap: no cryptographic proof that intents were actually enforced.
The Agent Passport System (APS) fills this gap. We just shipped an IBAC adapter that bridges IBAC tuples into APS delegations with Ed25519-signed receipts:
import { governIBACIntent } from 'agent-passport-system'
const result = governIBACIntent({
task: 'clinical_note_review',
subject: { id: 'agent-nurse-001' },
actions: [
{ verb: 'read', resource: 'table:patients', constraints: { sensitivity: 'phi' } },
{ verb: 'write', resource: 'file:clinical_notes' }
],
timestamp: new Date().toISOString()
}, { passport, delegation, privateKey })
// Each tuple evaluated against scoped delegation
// result.tupleResults[0].authorized === true
// result.receipt — Ed25519 signed proof of the evaluation
What APS adds to IBAC:
-
Cryptographic receipts. Every PERMIT and DENY is Ed25519-signed. An auditor can verify what was evaluated, when, and what the decision was — months after the fact.
-
Delegation chains with monotonic narrowing. Authority can only decrease at each transfer point. A sub-agent can never exceed its parent's scope. This is enforced mathematically, not by policy configuration.
-
Gateway as judge AND executor. The enforcement boundary sits at the mutation surface — the gateway evaluates AND executes, preventing TOCTOU gaps between authorization check and action execution.
-
Cedar/OPA bridge. The adapter includes cedarPolicyToTuples() and delegationToCedarPolicy() for round-trip conversion between Cedar-style policies and APS delegations.
Mapping:
| IBAC Concept |
APS Implementation |
| Intent parser output |
IBACIntent type → ibacIntentToScope() |
principal:action#resource tuple |
agentId:scope:target in Delegation |
| Cedar/OPA authorization engine |
ProxyGateway (15 constraints, <2ms) |
| Tool gateway |
Gateway as both judge and executor |
| Audit trail |
Signed receipt chain with previousReceiptHash |
Install:
npm install agent-passport-system # v1.35.0, 2,391 tests
SDK: npmjs.com/package/agent-passport-system
IBAC adapter source: src/adapters/ibac.ts
Live gateway: gateway.aeoess.com (governance attestation endpoint)
Paper: doi.org/10.5281/zenodo.19260073 (Faceted Authority Attenuation)
IBAC defines the intent. APS proves it was enforced.
APS as cryptographic enforcement layer for IBAC intent evaluation
The IBAC architecture describes: Intent parser → Policy mapper → Authorization engine → Tool gateway. This is the right model. The gap: no cryptographic proof that intents were actually enforced.
The Agent Passport System (APS) fills this gap. We just shipped an IBAC adapter that bridges IBAC tuples into APS delegations with Ed25519-signed receipts:
What APS adds to IBAC:
Cryptographic receipts. Every PERMIT and DENY is Ed25519-signed. An auditor can verify what was evaluated, when, and what the decision was — months after the fact.
Delegation chains with monotonic narrowing. Authority can only decrease at each transfer point. A sub-agent can never exceed its parent's scope. This is enforced mathematically, not by policy configuration.
Gateway as judge AND executor. The enforcement boundary sits at the mutation surface — the gateway evaluates AND executes, preventing TOCTOU gaps between authorization check and action execution.
Cedar/OPA bridge. The adapter includes
cedarPolicyToTuples()anddelegationToCedarPolicy()for round-trip conversion between Cedar-style policies and APS delegations.Mapping:
IBACIntenttype →ibacIntentToScope()principal:action#resourcetupleagentId:scope:targetin DelegationpreviousReceiptHashInstall:
npm install agent-passport-system # v1.35.0, 2,391 testsSDK: npmjs.com/package/agent-passport-system
IBAC adapter source:
src/adapters/ibac.tsLive gateway: gateway.aeoess.com (governance attestation endpoint)
Paper: doi.org/10.5281/zenodo.19260073 (Faceted Authority Attenuation)
IBAC defines the intent. APS proves it was enforced.