Guides
Request and evaluate a decision
How an enforcement point asks IntentControl whether a proposed action may proceed, obeys the answer and reports what it did. Documented ahead of release.
Release-gated · interface not public
Nothing on this page is callable today. Commercially, IntentControl is coming soon in TrustOps and not yet on sale; signed-in operation: not yet available; and there is no public decision API: no install command, credential or endpoint exists. When IntentControl is released this guide gains runnable steps.
IntentControl today · measured 2026-10-10
- Commercial capability
- Coming soon · not yet on saleTrustOps lists every plan as coming soon. Nothing can be bought or provisioned yet.
- Signed-in operation
- Not yet availableThere is no signed-in operation until the service is confirmed live.
- Public developer interface
- Release-gatedThere is no public decision API, endpoint, credential format or SDK. Nothing is enforced by ECZ-ID.
The decision loop
- An enforcement point intercepts a proposed action before it runs: an MCP tool call, an HTTP request, or a call site in your code.
- It describes the action: actor, action type and name, resource, destination, parameters, amount, currency, data classes, the Intent reference and whether it is a sandbox action. It gives the request a unique identifier.
- IntentControl evaluates the action against identity, trust state, Intent, authority, delegation, time, policy and every constraint, and returns one outcome with per-check results and enforcement guidance.
- The enforcement point obeys the outcome: run, block or hold.
- It reports what it applied. Only consistent reports from inline points, about recent enforce-mode decisions, count as enforcement evidence.
What the enforcement point must do
| Outcome | Obligation | Report |
|---|---|---|
| Allow | Run the action | Proceeded, or blocked if it could not be sent |
| Deny | Block. Never run it | Blocked |
| Review | Hold. Return the approval reference to the caller | Held for review |
| Indeterminate | Block, unless the low-consequence fail-open rule applies | Blocked, or proceeded fail-open |
| Unavailable | Block, unless the same rule applies | Blocked, or proceeded fail-open |
- Anything that is not a well-formed, in-date decision for this exact request is unavailable, and blocks.
- Fail-open is permitted only when every applicable policy allows it, the action is not high-consequence, and the point was registered for it. Denials and reviews never fail open.
- A point that receives no guidance treats the action as fail-closed and high-consequence.
- Input the point itself could not read is never failed open.
Idempotency and approvals
- A request identifier names one request. Within the current or previous UTC day, repeating it with the same request returns the recorded decision, marked replayed, at no charge. Repeating it with a different request is refused.
- A review opens an approval for that exact request. An owner or admin approves or rejects it in the TrustOps Dashboard; an enforcement point cannot approve. Approvals expire after 24 hours and are single-use.
- After approval, the caller repeats the same action with the approval reference and a new request identifier.
What to build today
- Route every consequential action through one choke point in your code. That is where an enforcement point will sit.
- At that choke point, run a live reliance check on the counterparty and apply your own policy. See verify before reliance.
- Log the actor’s ECZ-ID, the Intent reference, your request identifier and your decision for every consequential action.
Related
This page is explanation, not authority. Current state is only ever the live Resolver record. Live facts on this page were measured read-only on 2026-10-10.