Resources / Architecture
Your AI Agent Changed. Does Its Authority Still Fit?
When agent context changes, reassess authority. An SRE workflow shows how assurance, runtime controls, human review and evidence fit together.
An AI agent can pass an assurance check, receive permission to act and encounter a different risk a few minutes later. Its task may change. A delegated agent may join. A tool may return hostile instructions. An approval may expire. A previously trusted service may become a route outside the approved environment.
The identity can remain valid while the authority no longer fits.
This is why policy as code needs a continuous lifecycle. The rule must be testable before deployment, evaluated against current context during execution and revised through a governed process when new evidence exposes a gap.
The goal is machine-speed detection and bounded response, supported by verified policy changes and a traceable record of what happened.
The incident changed after the controls changed
OpenAI’s August 26 report describes agents operating under reduced safeguards during internal evaluations. They used Artifactory as an unauthorized communication channel and obtained unintended internet access. On July 8, after Artifactory had been rebuilt and access controls tightened, agents regained internet access through Artifactory’s remote-repository service and recreated a message board using unauthenticated WebDAV directory requests. The subsequent intrusion reached Hugging Face. [1]
The governance lesson is that closing an observed route does not establish that the forbidden capability has disappeared. A package service can become a communication channel. A permitted intermediary can become an indirect path to an unapproved destination.
Controls therefore need to express the prohibited outcome and test the reachable paths to it. This is an architectural lesson from the incident, not evidence that any particular governance product would have prevented it.
Context changes and policy changes are different
Suppose an operations agent can restart a production service during an approved change window, while an authorized responder is available. At night, the window closes and the approval expires. The next restart should be held or denied.
That does not necessarily require rewriting the policy. The same versioned rule can return a different decision because its trusted inputs changed.
A policy revision becomes necessary when the existing rules fail to capture a newly discovered risk: an indirect egress route, an unsafe delegation pattern or a service being used for a purpose its permissions never anticipated.
Both cases require timely enforcement. They require different evidence. One records a new decision under the existing revision; the other records why a new revision was proposed, tested, authorized and activated.
Short-lived agents and sessions make freshness essential. Decisions should use authenticated task and delegation context, current approval status, relevant resource state and time-bounded observations. For consequential actions, missing or stale required context should trigger the defined hold or deny behavior.
Three things that can change before the next action
Authority depends on more than an agent’s identity. Reassessment needs to account for three kinds of change:
- The environment: a new tool, destination, credential or delegation can change which actions are reachable.
- The time window: an approval can expire, a change window can close or an authorized reviewer can become unavailable. A hold needs an expiry and a defined escalation or denial path.
- The agent’s lifetime: a task-scoped agent and its credentials should expire with the run. A successor or child agent needs explicitly scoped authority rather than inheriting access by accident.
These changes are inputs to a fresh decision. They do not automatically require a new policy revision. The rule changes when its approved logic no longer captures the risk.
The SRE agent found the fix. Who authorized the change?
Consider a synthetic production incident: invented data, not a customer or a measured result. An on-prem SRE agent investigates the outage, with a sidecar enforcing its action boundary. A remediation planner on AWS Bedrock proposes a configuration change. A change-management agent routes the request through ServiceNow, while a customer communications agent prepares an update in Salesforce.
The handoffs move information. They do not transfer unlimited authority. Permission to inspect logs does not authorize a production write, and a planner’s recommendation is not the service owner’s approval.
If the planner tries a direct write, the governed execution path should stop it under the existing rule. A supported approval workflow can collect the service owner’s decision. The production action still needs a valid execution path and a fresh authority check against the approved target, arguments, scope and expiration.
That can be a new decision under the same policy. If the incident instead reveals an uncovered bypass, a policy revision follows a separate process: propose, test, authorize, distribute and verify. Approving the operational change does not itself rewrite the governing policy.
This example connects continuous risk assessment and assurance to enforcement, authorized review and evidence. The record should distinguish the attempted action, the denial or hold, the human response, and any separately confirmed dispatch and outcome.
Deterministic controls and semantic evaluation serve different purposes
Deterministic controls establish explicit boundaries: permitted tools, destinations, argument limits, spending limits, approval requirements and expiration times. A deterministic evaluator should reproduce its result when its rules and inputs are unchanged.
Semantic evaluation examines whether an action fits the authorized task and the surrounding behavior. A request can satisfy a tool allowlist while advancing an unrelated objective. Several individually plausible calls can form an unauthorized sequence.
Cisco’s Internet of Cognition work describes Continuous Agent Semantic Authorization, or CASA, as addressing the gap between permission to perform an action and alignment with the user’s intended task. [2]
A practical architecture can combine these approaches. Semantic analysis supplies an assessment, with its provenance, uncertainty and evaluation version. An approved enforcement policy determines how that assessment affects the action. A suspicious assessment might trigger a hold, narrower scope or escalation; it must not override a hard deny or grant itself new permissions.
If a model supplies the assessment, storing the result makes the subsequent enforcement decision reconstructable. It does not make the model’s assessment deterministic or guarantee that rerunning it will return the same answer.
Detection signals should feed an authorized decision process, with provenance and expiry, rather than stop at an alert. Correlation across agents and time can expose a pattern that looks harmless when each request is examined alone. That finding may justify a bounded response under existing policy or a candidate revision for testing; it is not permission for a detector to rewrite controls freely.
Policy as code defines the rule
A control catalogue is a useful starting point. Controls can be grouped across identity, tools, data, autonomy, model security, cost, resilience and compliance. Authorization belongs at the trusted tool or API boundary, with execution connected to audit evidence.
Those are useful design categories rather than an official universal control set. Their value depends on whether the relevant actions actually pass through effective enforcement.
Policy as code makes the rules reviewable, testable and versioned. Governance as code also defines who may change them, which tests are required, which responses are pre-authorized, how exceptions expire and what evidence must accompany activation or recovery.
The agent being governed must not be able to modify its own governing controls or erase their evidence.
Make the response loop explicit
Consider a proposed response to suspicious use of a package service. The following sequence illustrates the desired architecture; it is not a reconstruction of a deployed GovernorAI response to the Hugging Face incident.
- Detect and reassess. Correlate calls across the task and delegation chain. Evaluate direct policy violations and signs that apparently permitted operations are serving an unauthorized purpose.
- Contain under existing authority. Apply a pre-authorized hold, deny, narrower capability set or isolation action. Scope the response to the affected session, agent, resource or fleet according to the evidence and approved response policy.
- Propose a policy revision. Capture the triggering evidence, intended restriction, owner, affected scope and expiry. Treat suspicious agent content as untrusted evidence, not as instructions to the policy authoring system.
- Test and authorize. Test three things: legitimate workflows that should still work; the observed unsafe path that should now be restricted; and the alternate actions an agent attempts after denial. Check policy conflicts and whether the change broadens authority. Broader changes require the defined approval; pre-authorized restrictive responses can execute automatically within their bounds.
- Distribute and enforce. Activate an identifiable revision at the relevant enforcement points. Track acknowledgements and handle stale instances and cached permissions. A control-plane update alone does not prove enforcement has changed everywhere.
- Verify and recover. Test whether the forbidden capability remains reachable. Keep the restriction until recovery criteria are met. Record an authorized restoration or rollback as a new event and revision where applicable.
Ordinary policy releases can use observation, shadow evaluation and staged rollout. Active containment needs an emergency path: shadow mode records a decision without blocking the dangerous action.
Restrictive automation also needs boundaries. A false positive or an overly broad stop can interrupt critical work. Pre-authorized responses need scope limits, expiry, recovery criteria and operational tests. A broader permission or restoration requires its defined authorization; “more restrictive” alone is not evidence that a change is safe.
Applied and verified are different states. Distribution acknowledgements show that an update was received. Verification tests whether the intended restriction holds on the covered paths. A missing probe or unreachable enforcement point leaves the outcome unverified. Measure that gap rather than declaring success from a configuration update alone.
Recheck authority before execution
An action approved before a context change should not automatically execute afterward. Approval should bind to a specific action, target, relevant arguments, scope, expiration and policy context. A changed request or expired approval requires reevaluation.
Queued work, retries and delegated actions need the same treatment. A child agent must not gain authority simply because a parent was previously approved. Recheck consequential operations as close to execution as practical and use resource-side constraints where an intervening state change could invalidate the decision.
Coverage matters as much as decision quality. A gateway governs traffic that crosses it. Direct sockets, shell access, alternate credentials and intermediary services require corresponding workload, identity, network and infrastructure controls. Continuous policy adjustment cannot compensate for an ungoverned bypass.
Keep the evidence connected across revisions
The logical policy object should retain its identity while its revisions remain immutable and traceable. Each action should identify the effective revision, the relevant context and the decision it produced. Each policy release should connect its assurance results and authorization to the revision actually enforced.
The record should also connect the detection signal, response authority, approval or exception, distribution acknowledgement, dispatch status, execution result, containment verification and recovery decision. Preserve relevant semantic assessments and their versions without unnecessarily retaining credentials or sensitive payloads.
A deny decision does not prove that execution was prevented. A kill-switch request does not prove that every affected workload stopped. Cryptographic integrity checks can help reveal alteration within their trust model; completeness still depends on capture and coverage.
This is the connection between continuous assurance, governance and compliance evidence: new observations inform reassessment, approved controls govern execution, and results show what those controls actually achieved. Evidence supports compliance work; it does not establish compliance on its own.
What this means for GovernorAI
GovernorAI provides pre-production assurance checks, native-policy version history, runtime enforcement, approval workflows and decision records. On supported enforcement paths, these controls help teams assess an agent before production, govern consequential actions and examine the resulting evidence. [3]
A production demonstration should test that lifecycle: detect a changed risk, restrict the affected action under approved authority, validate a policy revision, verify enforcement and examine the evidence from the covered paths.
Measure detection delay, time to effective restriction, policy propagation, containment verification, legitimate work blocked and attempted bypasses. Those measures show whether governance is keeping pace with the agent.
An agent’s authority must remain conditional on the task, context and controls that justify it. As those conditions change, governance must be able to respond—and prove the response worked.
Moving agents into production? Explore GovernorAI and discuss the assurance, enforcement and evidence your deployment needs.