Permission, Execution, and Outcome Are Three Different Things
How authority, a controlled write boundary, and a separate result check work together around one consequential action.
A customer asks an AI agent to cancel an order. A support lead approves the request. Later, the agent reports success.
Three questions still need separate answers: was this particular cancellation authorized, did the operation pass through the required controls, and did the order actually reach the expected state?
An approval answers the first question. It cannot, by itself, answer the other two. This separation shapes how we build Witnora.
Permission describes what may happen
“This agent can manage orders” is too broad for reviewing a consequential operation. A useful authorization identifies the proposed action and its limits: the order, the environment, the permitted change, and any required human decision.
For example, approving cancellation of order A should not authorize cancellation of order B. Approving a test action should not authorize the same request in production. If the amount or target changes after review, the earlier approval should not quietly carry over.
Witnora’s action contracts bind authorization to the action being evaluated. The action assurance protocol describes how identity, a mandate, policy, and approval relate to execution and evidence. The purpose is to make an operator’s decision apply to a specific request rather than an open-ended conversation.
Execution control puts that decision in the write path
A rule has preventive value when the operation must pass through it before changing the target system.
Imagine an agent that holds an unrestricted payment credential. A separate dashboard could flag a refund as disallowed, but the agent might still call the payment API directly. The warning and the actual ability to write would be disconnected.
For a controlled path, the write credential belongs at a boundary the customer operates and controls. The agent submits its request through that boundary. Policy can hold the request for approval or reject it before the adapter dispatches the write. In the design-partner v0.2 path, a short-lived, single-use grant binds the permitted execution to the reviewed action.
This is how Witnora can help prevent an unauthorized operation on a connected path. The intervention happens while there is still a decision to make, before an after-the-fact incident report is needed.
That claim depends on deployment. If the agent retains another credential or an alternate route to the target, that route needs separate treatment. Installing an SDK alone does not establish that every possible write has been mediated.
Outcome verification asks what the system now shows
Authorized execution can still produce the wrong result. The target might reject a state transition, accept asynchronous work that later fails, or apply a change to an unexpected object.
A separate read-only probe checks the agreed result in the target system. For the illustrative cancellation, it reads the specified order and compares the returned status with the expected status. Its observation has a source, a scope, and a time.
This produces a more useful distinction than a single green checkmark:
| Question | Evidence to inspect |
|---|---|
| Was this allowed? | The applicable authority and action-bound approval. |
| Was execution controlled? | The grant, adapter boundary, and execution record. |
| Did it reach the expected state? | A separate observation of the specified object. |
If the probe cannot read the result, execution evidence remains execution evidence. An unavailable read must not become a successful outcome by default.
A receipt connects the answers
The execution receipt makes these pieces reviewable together. It should help an operator follow one request from its authority through execution to the observed state, without confusing record retention with prevention or a signature with business correctness.
A historical successful result also stays historical. It does not establish that a disconnected agent is healthy now or that tomorrow’s version will behave the same way.
The design-partner quickstart walks through these boundaries using a local emulator and separate Gateway, probe, and verifier roles. Its sandbox result is a way to inspect the mechanism; connecting a real provider requires acceptance for that specific write and read path.
For a first pilot, the useful unit is one operation with an owner and a clear success condition. We can then test whether a prohibited request is held, an approved request can proceed, and the result can be checked without relying on the agent’s account of what happened.