Agentic Transaction Governance · Early access
Your customers are sending AI agents. Govern every transaction they make.
The control layer that lets a platform safely accept transactions from AI agents acting on a consumer's behalf: verifying that a real human freely consented, constraining every transaction inside the token itself, and revoking an agent's authority in seconds.
Eniyan turns a consumer's consent into a governed delegation: scoped to a tier, capped per transaction, budgeted per window, limited to approved counterparties, and compiled into a 5-minute OAuth token your existing infrastructure can verify. Built on RFC 9396, introspected live, revocable in one call.
Willa's Grocery Agent
- Tier
- Execute, capped
- Per transaction
- $200.00
- Monthly budget
- $600.00 · $557.82 left
- Counterparties
- 3 approved merchants
- Consent
- CAL 3 · at grant
- Token lifetime
- 5 minutes
A live delegation: the terms ride inside every token it mints.
The problem
An agent at your checkout is not its user.
When an AI agent arrives holding a customer's session, you have three unanswerable questions:
- No proof the human consented, or was even present, or acting freely.
- No limits your systems can verify: the agent holds everything the customer can do.
- No way to cut it off mid-session without cutting off the customer too.
How it works
From consent to governed transaction in six steps.
01
Recognize the consumer
Your CIAM asserts the customer; Eniyan mints a pairwise pseudonymous subject. No PII crosses the wire: you keep the mapping.
02
Run the consent ceremony
The moment of consent is scored into a Consent Assurance Level (CAL), with hard caps for duress and coercion.
03
Activate the delegation
The grant becomes a durable record: tier, scopes, per-transaction cap, windowed budget, approved counterparties, expiry. One live delegation per customer–agent pair.
04
Mint the token
The agent presents its verifiable credential plus the delegation reference, and receives a 5-minute token: the consumer as subject, the agent as actor.
05
Verify and transact
Your API introspects (RFC 7662); Eniyan re-evaluates the delegation live at that moment. You report spend to the budget ledger as transactions execute.
06
Step up, or cut off
Sensitive transactions demand more proof: an in-app approval, a Stripe Identity check, or a passkey confirmation, bound to the exact amount shown. And revocation lands on the very next check.
Least privilege, by tier
Four tiers of authority. Four floors of consent.
Higher authority demands higher-assurance consent: an execute-tier grant cannot ride on a weak ceremony.
Read-only
See what the customer can see. No side effects.
Propose
Draft carts, itineraries, and payments: a human clicks confirm.
Execute, capped
Transact autonomously inside caps, budgets, and approved counterparties.
Execute, full
Manage the delegation's own boundaries. Demands the strongest consent evidence.
Consent Assurance Level
AAL measures the login. CAL measures the grant.
A strong password proves nothing about the moment a customer hands authority to an agent. CAL scores that moment across four evidence classes your platform attests, and refuses to be generous about missing evidence: absence of evidence is not evidence of safety.
Presence
Was a human actually there when authority changed hands.
Freedom
Were they acting freely, or under pressure from someone else.
Session integrity
Is the session itself trustworthy at the moment of the grant.
Comprehension
Did they see, and authorize: exactly the authority being granted.
Signals of duress or coercion cap the score outright. No amount of other evidence overrides them. The at-grant score is immutable, your audit answer to “what did we know when the customer consented.” The current score reprices as late signals arrive, and a delegation whose consent weakens below what its tier demands stops minting tokens until the customer re-affirms.
Verified step-up
Match the proof to the risk.
A threshold on an amount is the floor, not the ceiling. Demand a stronger factor for the actions that deserve it: an identity check, an MFA confirmation, or both, checked before any token exists.
Your policy decides
You choose which actions demand stronger proof, and which factor, or combination, satisfies it. Everyday actions stay frictionless; the strongest proof is reserved for the transactions that warrant it.
Identity verification
A Stripe Identity check: document, selfie, ID number for higher assurance. One check can cover many transactions, or you can require a fresh one for the riskiest moves. Consumer consent is captured before any biometric step.
MFA confirmation
For a sensitive action the customer confirms with a passkey or authenticator code: in your app, or on an Eniyan-hosted page that shows the exact amount and recipient.
Verified, not surveilled
Every factor is proof the customer supplies, never behavioral profiling. Document checks are Stripe-hosted; Eniyan records only the verification outcome, not documents, selfies, or biometrics.
The loop, end to end
Grant. Verify. Confirm. Revoke.
The same sequence our design partners run against a live sandbox: every response below is the product's real behavior.
What your customers see
Let customers see exactly what they delegated.
Give a customer a signed, Eniyan-hosted link and they see precisely what they authorized: the scopes, the caps, the budget and what's left, the expiry, and the step-up rules protecting them. No account, no PII: pairwise pseudonymous subjects only. It stays per-platform; nothing here is a portable consumer credential.
A clear receipt
Scopes in plain language, caps and remaining budget, expiry, and whether the delegation is live. It's the same authority your API enforces, shown to the person who granted it.
Only for approved agents
Hosted links carry an “Eniyan approved” seal: available only for agents that passed Eniyan's transparency review, and the page goes dark the moment that approval is withdrawn.
Yours to offer
Render the delegation hub in your own app for free, or turn on Eniyan-hosted view links as a paid add-on when you want the hosted page and the seal.
Evidence, not vibes
When a transaction is disputed, you have the whole chain.
- The consent ceremony and its CAL score at the moment of the grant
- The delegation terms: tier, scopes, caps, budget window, counterparties, expiry
- Every minted token's authorization_details: the exact transaction authorized
- Approval artifacts, bound to the amount the customer actually saw
- The spend ledger, and the revocation record with actor attribution
We never see your customer. You never send PII.
Consumers are pairwise pseudonymous IDs: you keep the mapping, and you never send us names, emails, or card numbers. The delegation path holds no personal data to breach, subpoena, or explain to a regulator.
One control layer, every vertical
Wherever your customers send agents.
Commerce & marketplaces
- Agentic checkout with per-order caps and windowed budgets
- Merchant and seller allow-lists enforced at the token layer
- Returns and subscription management as first-class scopes
Financial institutions
- Payment initiation with payee allow-lists and step-up over threshold
- Coercion-aware consent with hard caps for duress
- Immutable at-grant CAL plus the full chain for disputes
Travel & booking
- Propose-then-approve booking flows for high-consideration purchases
- Trip budgets as delegation windows, suppliers as counterparties
- Revoke the trip agent the moment plans change
Be the platform agents can transact with.
Consumer Delegation is in early access. Design partners get white-glove integration, founder pricing, and a seat at the table while the category is defined.