Autonomous systems create a distinction that ordinary descriptions of logging and governance can blur: recording an action is not the same thing as proving that the action had current authority to execute.

The useful question behind human approval ai agents is not only what evidence will exist afterward. It is also what must be true at the execution boundary before the side effect is allowed to happen.

Two different control questions

Audit trail: a record of events, decisions, approvals, tool calls or outcomes that can support reconstruction and accountability.

Execution authority: current, verifiable permission that an integrated executor must validate before it performs the governed side effect.

Demonstrated: backed by current implementation or bounded test evidence represented in the article's fact packet. It does not mean every possible execution path or external system is controlled.

A strong audit trail can contain identity, policy state, approvals, tool calls and side effects, including records created directly in a control path.

A log becomes governance evidence when it is tied to an enforced decision and the actual executor. A log created after an action is not, by itself, proof that the action was authorized before it happened.

Evidence and enforcement answer different questions

Question Audit or decision evidence Execution governance
Primary purpose Reconstruct what was proposed, decided or done Determine whether the governed action may proceed
Timing Can exist before, during or after activity Must still be valid at the execution boundary
Authority Can record identity, approvals and policy state Requires current authority for the exact governed action
Enforcement A record alone does not prove downstream enforcement The integrated executor verifies required authority before the side effect
Failure behavior Preserves evidence about the event or failure Can deny, hold or stop the governed side effect when required verification fails

This does not make audit trails less important. It separates evidence about a decision from authority enforced where an action becomes real.

A neutral worked example

An agent proposes:

approve_payment($25,000)

Audit-only path

In this example, logging is present but is not connected to an execution-enforcement boundary.

  1. The agent proposes the payment.
  2. The payment executes.
  3. The system records the action, identity, tool call and outcome.
  4. A reviewer may later discover that the agent exceeded its authority.

This is not a claim that every audit system behaves this way.

Execution-governed path

  1. The agent proposes the payment.
  2. Identity, delegated authority or capability, amount, recipient and current policy are evaluated.
  3. The applicable policy allows, denies or requires additional approval.
  4. The executor verifies the required authority before performing the payment side effect.
  5. If required verification fails, the governed payment does not proceed.
  6. The decision, verification result and execution outcome are recorded.

The architectural distinction is not logging versus no logging. It is whether the decision and evidence are connected to the executor that can actually cause the side effect.

Control requirements

For this topic, the relevant control layers are Human Approval.

A bounded governed path should answer:

  1. Which principal or agent is acting?
  2. What authority or capability has actually been delegated?
  3. What exact action and arguments are being proposed?
  4. What does current policy allow for this context?
  5. Is additional human approval required?
  6. Is the authorization still fresh?
  7. Has authority been revoked?
  8. Has this authorization or exact action already been consumed?
  9. Will the executor independently verify the required evidence?
  10. What evidence connects proposal, decision, verification and outcome?

Independent market context

  • Fiddler AI: Fiddler describes its AI Control Plane as combining agent observability, inline policy enforcement, and auditable governance.
  • Amazon Web Services: AWS states that every agent tool invocation should be authorized against declarative policy before execution, with agent identity and originating user context carried through the authorization chain.
  • Model Context Protocol: The official MCP project explains that tool annotations can describe behaviors such as read-only or destructive operation, but they do not prevent prompt injection and are not enforcement; clients must treat annotations from untrusted servers as untrusted.

These sources provide independent market context. They are not endorsements of Sentinel, do not imply partnership, and do not establish identical technical guarantees.

How this maps to Sentinel

In a Sentinel-governed path, a proposed action is evaluated before execution. Where an applicable integration uses action-bound authorization, that authorization is bound to the governed action and the integrated executor verifies the required evidence immediately before the side effect.

An ALLOW record alone is not represented as proof of downstream enforcement. Evidence artifacts are also not treated as authority for a new governed side effect.

Sentinel demonstrated evidence

The following statements are included only because the bound fact packet marks them DEMONSTRATED:

  • Sentinel uses fail-closed behavior on governed execution paths. Evidence: Existing governed execution tests; EET-1 negative-path matrix.
  • Sentinel binds authorization evidence to a canonical action digest. Evidence: Canonical action digest implementation; Executor verification path.
  • Sentinel uses Ed25519-signed authorization evidence on governed execution paths. Evidence: Ed25519 decision-package signing; Local signature verification.
  • Sentinel checks permit freshness using bounded validity windows. Evidence: Permit TTL; Executor expiry verification.
  • Sentinel rejects replay of previously consumed governed actions. Evidence: Executed action ID state; Executed action-hash state; EET-1 replay test.
  • On bounded integrations, the executor locally verifies authorization evidence immediately before the side effect. Evidence: Codex EET-1 file-write integration; Executor verification implementation.

The statements remain bounded to the implementations and tested paths represented by their evidence.

Practical next step

If your agent can change infrastructure, records, data, or financial workflows, identify the exact execution boundary, define what authority must be present, and test whether the executor verifies it before the side effect.

Sentinel's governed path applies that distinction by evaluating the proposed action, binding authorization to the governed action where applicable, requiring verification at the integrated execution boundary, and preserving the resulting decision and execution evidence.

Research basis

Source provenance, retrieval timestamps and evidence bindings remain in the factual research packet rather than interrupting the reader-facing narrative.

Boundary statement

Execution claims apply only to Sentinel-governed and tested paths.

An ALLOW or DENY response alone does not establish downstream enforcement.

Direct or alternate execution paths that bypass the governed boundary are not represented as controlled by Sentinel.