An approval should authorize one defined operation. It should identify the actor, action, resource and inputs being approved, and the execution path should check that those details still match before it calls an external system.
“Ask me before sending” is a useful instruction. A working approval boundary also needs code that can refuse a changed, expired or repeated request. This guide describes what to inspect in that boundary and where a policy library ends and the consuming application begins.
Start with the operation the person can actually review
Consider an assistant preparing an email. The owner reviews a message and approves it. Before dispatch, the assistant changes the recipient or adds an attachment. The tool name is still “send email”, but the operation is different.
Approving the tool name alone cannot distinguish those requests. The review needs a frozen representation of the intended operation. For an email, that might include the mailbox, draft identity and revision, recipient set, attachment references and a digest of the exact message content. The person should see the meaningful details rather than an unexplained hash.
The representation is specific to the application. An email draft, a deployment and a record update need different fields. The principle is the same: changes to consequential inputs invalidate the old approval.
Separate technical access from permission to act
A credential answers whether an application can reach a service. It does not establish that a particular agent may perform a particular operation in the current task.
Check the boundary in layers:
- Identity: derive the actor from the authenticated request, rather than a name supplied in message content.
- Scope: establish which action and resource are permitted by the active policy.
- Approval: verify the approver, exact request binding and validity window when the policy requires approval.
- Dispatch: call the reviewed implementation with the validated inputs.
- Outcome: retain a receipt and reconcile uncertain external results before a retry.
Each layer has a different job. A signed policy bundle does not authenticate an email sender. An approval record does not dispatch a tool. An HTTP success response may still need provider-side verification before the application can claim the intended outcome.
Bind approval to normalized inputs
Equivalent requests should have a defined representation before they are hashed or compared. That normalization must preserve details that matter to the operation: changing a recipient, amount, target environment or attachment cannot disappear in the process.
A request-bound approval record typically needs the following fields:
- Agent and authenticated actor identity.
- Action and exact resource scope.
- Digest of normalized operation inputs.
- Draft, artifact or configuration revision where relevant.
- Session or workflow identity when authority is session-scoped.
- Approver identity and applicable approval role.
- Issue time, expiry and policy revision or other invalidation rules.
- A unique identifier used by durable replay protection.
These are design questions, not proof that a particular installation implements them. Inspect the actual request construction, verifier and dispatch path. A boolean called “approved” is insufficient if any caller can supply it.
Keep the approver outside the agent's authority
The same principal should not gain approval power merely because it can request an operation. Check how the application authenticates the human decision and which tools are visible to the agent.
Hlinor Agent Registry can evaluate supported approval policies, but ordinary policy signals still come from the caller. The consuming application must verify those signals. For stronger request binding, the public project documents signed approval tokens and a trusted runtime binding. Those components still require correct identity, key and state management by the integration.
The distinction matters when reviewing a demo. A synthetic test may pass a matching approval object directly. That proves the tested policy behavior. It does not prove an untrusted caller cannot manufacture the same object in production.
Test what happens after the first attempt
Replay protection needs durable state shared by the execution paths that can attempt the operation. A flag in one process can disappear on restart or fail to protect another instance.
Useful negative tests include:
- The resource changes after approval: reject before dispatch.
- One input or artifact revision changes: require a new approval.
- Approval expires or current authority is revoked: reject.
- The same approved request is submitted twice: return the recorded state without repeating the protected operation.
- Policy or required audit storage is unavailable: do not silently proceed.
- The external call times out after dispatch: retain an uncertain state and reconcile it before considering another attempt.
The last case deserves its own test. Avoid describing a local dispatch claim as a universal exactly-once delivery guarantee. An external provider can accept an operation while the client loses the response. The application needs a provider-specific reconciliation strategy, not a blind retry.
What the public Mail Hub example demonstrates
The public Registry case study documents a Mail Hub integration with exact-draft owner approval, durable dispatch claims and replay checks. Its recorded acceptance cycle included SMTP acceptance, a provider Sent copy, consumed approval and a replay that did not submit another message.
That is useful evidence for the reviewed integration and cycle. It is not a fresh acceptance test of every mailbox, provider or later deployment. The library, consumer and external service each contribute to the result.
A review should leave a traceable answer
For one consequential operation, ask the team to show the proposed inputs, policy decision, approval binding, dispatched implementation and outcome record. Then change one meaningful input and demonstrate that the previous approval no longer authorizes it.
If those records cannot be connected, the finding is concrete: the team cannot yet reconstruct why that operation was allowed. The next step is to repair that boundary and test its failure paths before expanding the agent's authority.
Sources and next step
- Registry runtime enforcement boundary.
- Signed approval tokens.
- Trusted runtime binding.
- Documented Mail Hub acceptance.
Need an independent review of your agent's permissions, approvals and evidence? See the Agent Governance Review or send a short, non-confidential description of the system.