Access, intent and impact are three different facts
OAuth and workload identity can establish who may reach a service. They do not by themselves prove that a particular agent action is appropriate for its current purpose, arguments, destination and delegation chain.
A policy decision made away from the real executor can also become stale or disconnected. Arguments may change, the destination may differ, or a downstream agent may receive more authority than the manager was allowed to delegate.
The AgenticDome Verified Action Chain binds those facts through a compact Action Passport, receiving-boundary verification, structured action events and an outcome receipt. The public contract describes the claims and verification boundaries; signing keys and proprietary policy analysis remain private.
What changes when AgenticDome is in the path
For a supported protected path, bind the tenant, actor, workload, purpose, exact action, argument digest, destination digest, delegation lineage, policy version and trust epoch to a short-lived, single-use passport. The receiving runtime verifies the passport before admission. Outcome evidence then binds the observed action, result class and non-sensitive side-effect reference back to the same chain.
The protocol answers four assurance questions
Each answer has a distinct issuer and evidence level; an SDK report is not silently upgraded into gateway or destination assurance.
What was authorised?
Digests bind the exact action, arguments and destination without requiring raw sensitive values in the portal evidence.
Who delegated authority?
Parent and child actions preserve bounded delegation lineage rather than treating every downstream agent as independently trusted.
Where was it enforced?
The receiving gateway or executor verifies expiry, single use, policy/trust binding and destination before permitting impact.
What happened?
Outcome receipts record not attempted, rejected, accepted, succeeded, partial, failed, rolled back or unknown outcomes at their stated assurance level.
MCP authorization remains essential
The MCP authorization specification protects transport-level access using OAuth mechanisms and resource binding. Keep it. A Verified Action decision is additive: it applies tenant business policy to the exact operation travelling through an application-controlled boundary.
How AgenticDome creates the control point
1. Establish trusted context
Authenticate the actor and workload through the existing identity architecture and provide only context the integration can substantiate.
2. Issue a bounded passport
Create a short-lived authorization for one exact action and destination under a named policy version and trust epoch.
3. Verify at the receiver
Reject expired, replayed, altered, incorrectly delegated or destination-mismatched authority before execution.
4. Record the action chain
Link requested, authorised, admitted, attempted and outcome events with digests and tenant-scoped identifiers.
5. Close with outcome evidence
Use SDK-reported, gateway-observed or optional destination-attested evidence without representing one assurance level as another.
What this changes for real teams
Bind authorization to the real call
“Our pre-check can pass while the actual HTTP request changes.”
AgenticDome contribution: The execution boundary verifies the action and destination bindings immediately before the supported outbound operation.
Constrain multi-agent authority
“A manager agent should not give a specialist broader power than the task requires.”
AgenticDome contribution: Nested action identifiers and delegation claims preserve the permitted lineage and reject mismatched downstream execution.
Inspect machine-verifiable evidence
“We need more than a dashboard assertion that a tool call was checked.”
AgenticDome contribution: Tenant-scoped bundles expose hash links, public receipt claims and verification instructions while excluding source, prompts, raw arguments and secrets.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| Authorisation replay | A valid decision reused for another attempt can create an unintended second side effect. | Use short expiry, unique identifiers, single-use admission and replay-state checks at the receiving boundary. |
| Action or destination substitution | Approval for one operation must not authorise different arguments, method or target. | Compare exact canonical digests at admission and record any authorised-versus-observed deviation. |
| Delegation inflation | Authority may expand as work moves through manager and specialist agents. | Bind parent action, source, target, purpose and permitted operation through the verified delegation chain. |
| Unsubstantiated completion | An allowed decision does not prove the destination completed the operation. | Record the issuer and assurance level; optionally verify a destination signature for supported high-assurance integrations. |
A practical path to production
Choose consequential actions
Begin with operations that change money, permissions, data, infrastructure or external state.
Bind the real boundary
Ensure the passport is checked where the application still controls the actual side effect.
Protect signing authority
Keep private keys at their authorised issuer and define explicit rotation and trust-epoch procedures.
Test misuse
Exercise expiry, replay, argument mutation, destination mismatch, delegation mismatch and missing-receipt cases.
Where this control ends
The Verified Action Chain applies only to supported paths that issue and verify its evidence. It does not replace IAM, OAuth, resource authorization, secure tool implementation, transactional guarantees, destination logs, human approval, rollback or incident response. A signed receipt proves only the claims and assurance level its trusted issuer can substantiate.
Current lifecycle note
Protocol and bundle schemas are versioned. Customers should keep portal, public SDK or plugin, runtime image and tenant policy on compatible signed releases before treating a chain as fully verifiable.