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 ai control plane 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.
- The agent proposes the payment.
- The payment executes.
- The system records the action, identity, tool call and outcome.
- 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
- The agent proposes the payment.
- Identity, delegated authority or capability, amount, recipient and current policy are evaluated.
- The applicable policy allows, denies or requires additional approval.
- The executor verifies the required authority before performing the payment side effect.
- If required verification fails, the governed payment does not proceed.
- 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 Policy, Execution Boundary.
A bounded governed path should answer:
- Which principal or agent is acting?
- What authority or capability has actually been delegated?
- What exact action and arguments are being proposed?
- What does current policy allow for this context?
- Is additional human approval required?
- Is the authorization still fresh?
- Has authority been revoked?
- Has this authorization or exact action already been consumed?
- Will the executor independently verify the required evidence?
- What evidence connects proposal, decision, verification and outcome?
Independent market context
- IBM: IBM describes watsonx.governance as providing AI governance capabilities including policy enforcement, monitoring, traceability, and governance evidence.
- Fiddler AI: Fiddler describes its AI Control Plane as combining agent observability, inline policy enforcement, and auditable governance.
- PortEden: PortEden describes AI-agent governance around agent identity, scoped or least-privilege access, and audit trails.
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.
- Sentinel maintains tamper-evident append-only audit evidence. Evidence: Audit hash chain; Canonical digest evidence.
- Sentinel does not treat read-only replay or evidence artifacts as execution authority. Evidence: artifact_class enforcement; execution_authority guard; not_valid_for_execution guard.
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.
- Review Sentinel Proof
- Review Sentinel security boundaries
- Read the integration quick start
- Apply for a bounded founding integration
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.