AI Agent Governance: Evidence Is Not Authority

Introduction

The certificate investigation now has a better timeline. Delayed logs challenged the claim that a recent certificate change initiated the authentication failures, and the workspace marked the earlier proposal for revalidation.

OWASP’s Transaction Authorization Cheat Sheet recommends presenting significant transaction details, protecting them from modification, and checking authorization at execution. The application here replaces transaction details such as a destination account with infrastructure details such as target identity, artifact revision, and permitted operation.

A consumed approval should not become fresh permission when an invocation is retried. Continue or reconcile the same recorded operation under its defined rules. Part 3 will examine these recovery cases in more depth.

A single trusted flag is too ambiguous for this design. It might mean that a source was authenticated, a statement was checked, a human approved a proposal, or an executor received permission. Those are different claims.

Suppose a retrieved incident note claims that the incident commander has already approved a fleet-wide change. The retrieval specialist includes the sentence in its summary, and the planner repeats it as part of the remediation rationale.

The original receipt remains a record of what was approved. It does not satisfy the new requirement by itself.

For this production-mutation example, inability to establish required authorization blocks dispatch. That does not necessarily prohibit independently authorized read-only diagnostics. Any emergency route must have its own defined authority, scope, and audit path, rather than becoming an automatic fallback after ordinary authorization fails.

Separate What the System Knows from What It May Do

Where supported, make the target enforce a resource-version precondition on the mutation. RFC 9110 defines HTTP If-Match using strong entity-tag comparison, which can prevent applying a change to an unexpectedly modified representation. That protects the selected resource representation, not every dependency or the complete authorization state.

Question	Evidence needed in this design	What it does not establish
Who produced this record?	Authenticated origin and protected provenance	That its contents are correct
What has been verified?	A defined check, its scope, and its result	That every related hypothesis is true
What did the approver accept?	A protected approval record bound to specific action details	That execution remains permitted indefinitely
May this executor act now?	Applicable policy, valid authority, satisfied conditions, and target authorization	That the action will achieve its intended outcome

A shared workspace can improve coordination without making its conclusions authoritative. Evidence supports a claim. Approval records a bounded decision. Authorization determines whether a particular executor may attempt a particular action under the conditions that apply now.

This YAML describes the new one-instance proposal. It is not a native schema for an agent framework, an authorization token, or a runnable certificate procedure. The identifiers and workspace version are illustrative continuations of Part 1.

Also distinguish permission to submit a proposal from permission to execute it. A read-only planner may request review without receiving write access. The executor acts under an approved workflow or valid delegation, with the initiator, approver, and executing workload recorded separately.

Carry the Incident to a Bounded Action

An authorization result should carry a stable decision identifier and an actionable reason. Distinguish denied, approval_required, revalidation_required, and temporarily_unavailable; only an explicit permit with satisfied conditions should admit the action.

Preserve the original artifact revision, producer, task scope, timestamps, and transformation lineage when specialists summarize evidence. A trusted summarizer may produce an accurate account of an untrusted claim. That does not promote the claim into trusted policy.

Changing the target, bundle, reload behavior, or adapter semantics creates a new reviewable action. The executor must dispatch from the approved manifest, not ask another model to reconstruct its arguments.

For the certificate adapter, define whether a multi-step operation is admitted as one bounded workflow or requires revalidation before each material step. Cancellation should stop future steps where supported; it must not be reported as proof that completed effects were undone.

The useful measure is not how often the agent receives approval. It is whether the organization can explain and enforce the relationship between a requested change, its permitted scope, and its observed effects.

Keep Policy Outside the Competition for Attention

A compact acceptance matrix makes the expected behavior reviewable before implementation.

Join the decision record to the protected approval, manifest revision, executing identity, target operation identifier, and external validation result. Preserve evidence of denied attempts as well as successful ones. Exclude credentials and private keys, and apply access and retention controls to the remaining audit data.

In the proposed architecture, a policy decision component evaluates structured requests. An execution gate enforces the result and its conditions. An approval service records decisions by authenticated, authorized approvers. These are logical responsibilities; they do not require separate products, but they must not collapse into the planner’s discretion.

Authorization Cheat Sheet distinguishes authentication from authorization and recommends least privilege, default denial, and permission checks on every request. Applying those principles here means that confidence, agreement, and source authenticity cannot substitute for an execution decision.

New articles

Notice the two controlled boundaries in the diagram. Admission and disclosure rules constrain shared evidence. A separate execution gate controls consequential actions. Neither receives its authority from workspace consensus.

The same distinction prevents circular confirmation. If the planner, evaluator, and reporter all derive their conclusion from one runbook, there is still one documentary origin. Another model reviewing the same text may contribute analysis, but it has not collected another operational observation.

Preserve Provenance Through Summaries and Broadcasts

The platform team owns the gate and manifest enforcement. Security and identity owners define policy, delegation, revocation, and emergency access. Application owners approve tool semantics, disruption limits, validation, and recovery procedures.

Policy updates should arrive through the policy publication process. Approval decisions should arrive through the approval service. Neither should be accepted because a retrieved paragraph imitates the right format.

Part 1 introduced workspace versions to identify the state behind a proposal. Authorization needs additional versioning because the rules governing the action can change while the proposal remains identical.

Separate a case record from a reusable procedure and from executable policy. A future task may retrieve the incident as a reference, but it still needs current applicability checks and authorization. Similar symptoms do not make the earlier receipt reusable.

A reviewer needs to understand the proposed change, but the enforcement system needs something more precise than an incident summary.

For the design in this series, it does not. The system must recognize that the executable action changed, regardless of how persuasive the explanation becomes. This is where shared coordination becomes an AI agent governance problem.

This is an illustrative extension of the incident, not a reported finding. It supports investigating a local discrepancy. It does not resolve why some failures preceded the earlier configuration change.

Approve an Immutable Action, Not a Narrative

Suppose a human approves the manifest while policy epoch 17 permits a single designated approver. Before dispatch, epoch 18 takes effect and requires two approvals for this production operation.

Define approval carryover explicitly. An unrelated workspace bookkeeping event need not invalidate the action, while material counterevidence can require renewed review even when the manifest’s executable fields are unchanged.

The adapter contract must identify effects the underlying operation can trigger. A one-resource request can still invoke a shared deployment controller or initiate follow-on work. Have the application owner validate those dependencies before classifying the action as narrowly scoped.

For stronger revocation semantics, define where execution is admitted and how a policy change is ordered against that admission. The target or trusted execution service must enforce the corresponding version, lease, or fencing mechanism. A database lock in the workspace cannot order an unrelated remote side effect.

An Illustrative Action Manifest

For the certificate incident, the standard is concrete: approval of one-instance remediation must not become permission for a fleet-wide change, even when every agent agrees that expansion sounds useful.

Continue with the path that best matches the architecture or operating challenge in front of you.

TL;DR

Likewise, max_targets: 1 is not a system-wide capacity guarantee. Several incidents could each submit a one-instance change against the same service. Enforce shared concurrency and capacity limits at the service execution boundary, not only inside individual workspaces.

Bind an admitted operation identifier to its exact manifest. Reject reuse of that identifier with different parameters. The executor and target integration need an explicit duplicate-handling contract; an idempotency key in a request does not make an arbitrary remote operation execute exactly once.

Notice that the manifest contains no approved: true field. Approval and execution decisions are separate protected records. A valid manifest is eligible for evaluation, not automatically eligible for execution.

Revalidate Authority When Execution Becomes Possible

A configuration service can be authoritative about the configuration it recorded without being authorized to approve remediation. An approved runbook can describe a procedure without granting the agent permission to use it against production.

Historical approvals are particularly dangerous as retrieval shortcuts because they can look like institutional permission. Keep them distinguishable from current control decisions, including in summaries and operator-facing reports.

Part 3, AI Agent Reliability: Test the Whole Coordination Loop, will examine whether these boundaries hold through duplicate messages, delayed evidence, component failures, interrupted execution, and uncertain outcomes.

The investigation identities remain read-only. A separately authorized executor performs any approved mutation. Changing a workspace field from read_only to write_enabled must never be a permission-escalation mechanism.

A review screen should therefore show the selected instance, configuration change, expected disruption, unresolved evidence, and recovery limitations. Build its authoritative fields from the stored manifest, not solely from a model-generated summary. Never show an approval prompt that says only, “Approve the recommended fix.”

OWASP’s LLM06:2025 Excessive Agency identifies excessive functionality, permissions, and autonomy as distinct risks. Its recommendations include narrower tools, minimum downstream permissions, and approval for high-impact actions. A careful prompt does not replace those controls.

When that coordination is unavailable, document the residual interval and restrict which operations may use the path. Do not advertise instantaneous revocation or atomic authorization based on a last-second policy lookup.

Use an action manifest: a structured description of the operation, exact resources, arguments, expected effects, and required checks. In this proposed design, the approval binds to an immutable manifest revision and the evidence snapshot presented for review.

For this example, assume the adapter exposes bounded operations, the target has enforceable access controls, and approval records live in a protected service. Where those prerequisites are missing, stop at a recommendation for the existing human-operated change process.

The original Global Workspace Theory discussion separates the cognitive workspace, policy boundary, and authority layer. This article develops those boundaries into a proposed engineering model, using established authorization guidance where relevant. It is not a standardized GWT security architecture or a claim that a particular agent framework implements these controls automatically.

Keep exploring

The text is now in a trusted application’s output, but its claimed approval still originated in a document. In this design, it remains evidence about what that document says, not an approval-service record.

Now consider the next boundary. A revised investigation identifies a configuration discrepancy on one application instance. The planner proposes a narrowly scoped correction. An evaluator finds the procedure applicable, and an operator approves it.

A policy epoch identifies the applicable policy state in this design. It should map to identifiable policy artifacts, not just an arbitrary counter. Keep relevant identity, delegation, and resource attributes identifiable too: a policy revision alone does not capture a revoked permission or changed tenant assignment.

Does the original approval still apply?

schema_version: “example-v1”
action_id: “action-009”
manifest_revision: 1
workspace_id: “incident-042”
basis_workspace_version: 24
proposal_id: “proposal-009”

scope:
tenant_id: “tenant-a”
environment: “production”
service: “payments-api”
target_resource_id: “instance-7c91”

operation:
adapter: “certificate-operations”
adapter_revision: “cert-ops-r3”
name: “apply_approved_bundle”
parameters:
bundle_artifact_id: “cert-bundle-042-rev1”
reload_tls_configuration: true

evidence:
snapshot_id: “evidence-024-rev1”
required_observations:
– “obs-chain-check-021”

preconditions:
target_resource_version: “73”
required_checks:
– “certificate_artifact_eligible”
– “instance_capacity_safe”

limits:
max_targets: 1

expected_effects:
– “replace_certificate_bundle”
– “reload_tls_configuration”

validation_plan_id: “validate-payments-tls-v2”
recovery_plan_id: “recover-payments-tls-v3”

Before execution, the planner expands the target from one instance to every instance running the service. Its explanation sounds reasonable: applying the same configuration everywhere should prevent recurrence.

Begin by exercising this path without production writes. Demonstrate that changed targets, forged approval claims, expired authority, and unresolved prior dispatches cannot silently advance. Then introduce one narrowly defined operation with a clear owner and a measurable operating benefit.

The workspace establishes what deserves consideration. The authorization path establishes what may be attempted.

Do Not Turn an Approval into Persistent Memory

OWASP’s LLM01:2025 Prompt Injection describes indirect injection through external content and recommends separating such content, constraining privileges, and requiring approval for high-risk operations. Treating retrieved instructions as data is part of the defense, not a guarantee that a model will never follow them.

Recovery requires its own authorization treatment. A previous configuration may no longer be acceptable, and reversing the main write does not necessarily reverse external messages or other downstream effects. A recovery plan reference is not an unrestricted rollback grant.

An approval service can bind its receipt to a digest of a defined canonical representation of the manifest. Do not hash arbitrary YAML formatting or assume an unprotected hash proves who approved anything. Protect the receipt’s issuer, integrity, scope, expiration, and revocation state through the chosen service or cryptographic protocol.

The incident history should preserve that a particular approver accepted a particular action. The reusable knowledge store should not convert that event into “certificate repairs are preapproved.”

Put Ownership at Each Boundary

The operating team needs a handoff that answers why an action is blocked and who can resolve the condition. A policy-service failure is not a model-quality incident; an ineligible certificate artifact is not an invitation to change the approval policy.

Receive new enterprise AI and hybrid platform articles when they are published.

For this design, qualify operational lessons before promoting them to memory. Preserve the deployment scope, evidence, validation result, limitations, and review conditions. A successful repair on one instance does not establish that the same procedure is appropriate for every certificate-related outage.

For this example, approval covers one instance and the listed configuration effects. It does not authorize fleet-wide repair, certificate revocation, changes to trust stores, or messages to customers.

Conclusion

Checking immediately before dispatch reduces the interval between authorization and action. It does not make a distributed workflow atomic.

Open Policy Agent’s Decision Logs documentation describes recording policy inputs, results, decision identifiers, and policy-bundle revisions, with mechanisms for masking sensitive data. Those facilities can support the authorization record, but they are not proof that a tool obeyed the decision.

A role name in generated JSON is not authenticated identity. Trusted services must establish those identities and their permitted relationships. Human approval cannot expand the approver’s own delegated authority or override a target-system restriction by itself.

Continue with one tenant, the production service payments-api, and read-only investigation components. Assume an additional, independently collected endpoint check finds that one instance presents a certificate chain inconsistent with its approved configuration.

External References