TL;DR
AI agent governance must separate evidence, approval, and permission to execute. A shared workspace can coordinate a convincing recommendation without granting any component the authority to act. Preserve provenance through summaries, bind approvals to exact operations and resources, and recheck authorization when the action reaches execution. Keep production credentials outside the reasoning components, account for downstream side effects, and prevent old approvals from becoming reusable memory. The goal is not another agent that recommends caution. It is an execution path that cannot proceed without satisfying independently enforced conditions.
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.
That was the problem addressed in Part 1, Designing a Shared Workspace for AI Agents: when evidence changes, dependent plans must become reviewable.
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.
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.
Does the original approval still apply?
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.
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.
Separate What the System Knows from What It May Do
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.
| 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 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.
OWASP’s 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.
The workspace establishes what deserves consideration. The authorization path establishes what may be attempted.
Carry the Incident to a Bounded Action
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.
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.
The new proposal is to apply a specific eligible certificate bundle to that instance and reload its TLS configuration through a purpose-built adapter. Application owners must establish that the procedure, capacity conditions, and validation checks fit the service. No private key material should enter the workspace.
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.
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.
Keep Policy Outside the Competition for Attention
The workspace can rank candidate explanations. It should not rank an explicit security restriction against a model’s argument for ignoring it.
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.
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.
Keep the planner’s credentials incapable of bypassing the gate. Restrict alternate paths such as a generic shell, an unrestricted HTTP client, or a connector carrying broader production privileges than the approved operation requires.
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.
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.
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.
Preserve Provenance Through Summaries and Broadcasts
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 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.
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.
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.
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.
For the certificate incident, the endpoint check and the configuration record contribute different evidence. Three summaries of the configuration record do not. Preserve that distinction when presenting the case to a human approver.
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.
Approve an Immutable Action, Not a Narrative
A reviewer needs to understand the proposed change, but the enforcement system needs something more precise than an incident summary.
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.
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 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.”
An Illustrative Action Manifest
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.
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"
Replace the operation, identifiers, checks, and plans with reviewed equivalents for the real service. The evidence snapshot must retain counterevidence and unresolved questions, not just the observation favorable to the proposal. The named validation and recovery plans also need immutable, retrievable definitions.
Validate candidate fields against trusted inventory and adapter schemas before freezing the manifest. Resolve the target’s tenant and environment independently; do not trust the planner to label an out-of-scope resource correctly. Reject unknown parameters and unsupported adapter revisions.
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.
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.
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.
Revalidate Authority When Execution Becomes Possible
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.
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.
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.
The original receipt remains a record of what was approved. It does not satisfy the new requirement by itself.
Apply the same principle to an expired receipt, revoked delegation, invalidated evidence, or changed resource precondition. Do not replace the historical record. Record the new decision and explain which requirement is unsatisfied.
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.
Be Precise About the Remaining Race
Checking immediately before dispatch reduces the interval between authorization and action. It does not make a distributed workflow atomic.
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.
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.
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.
Govern Side Effects, Not Just the Named Tool
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.
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.
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.
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.
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.
Make Uncertainty and Denial Observable
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.
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.
A compact acceptance matrix makes the expected behavior reviewable before implementation.
| Condition at the boundary | Expected behavior in this design |
|---|---|
| Retrieved text claims approval | Require a valid approval-service record |
| Approved target is changed or expanded | Reject the mismatch and require a new manifest review |
| Applicable policy adds an unmet requirement | Withhold execution pending satisfaction of that requirement |
| Target version no longer matches | Stop the mutation and reassess the plan |
| Required policy or identity state cannot be established | Block production dispatch and expose the dependency failure |
| A prior dispatch timed out with unknown outcome | Reconcile the existing operation before attempting another mutation |
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.
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.
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.
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.
Do Not Turn an Approval into Persistent Memory
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.”
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.
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.
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.
Put Ownership at Each Boundary
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.
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.
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 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.
Conclusion
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.
Build those distinctions into separate records and enforceable transitions. Preserve provenance, bind approvals to immutable action details, keep credentials outside the planner, and address policy changes at the execution boundary. Account for side effects and keep historical approvals out of reusable permission logic.
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.
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.
External References
- OWASP: Authorization Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html - OWASP Gen AI Security Project: LLM06:2025 Excessive Agency
Canonical URL: https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ - OWASP Gen AI Security Project: LLM01:2025 Prompt Injection
Canonical URL: https://genai.owasp.org/llmrisk/llm01-prompt-injection/ - OWASP: Transaction Authorization Cheat Sheet
Canonical URL: https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html - RFC Editor: RFC 9110: HTTP Semantics
Canonical URL: https://www.rfc-editor.org/rfc/rfc9110.html - Open Policy Agent: Decision Logs
Canonical URL: https://www.openpolicyagent.org/docs/management-decision-logs
TL;DR AI agent evaluation should establish what the agent attempted, what actually executed, and whether the resulting service state met the requirement....