Governance
Configure fix approvals, protected paths, and account settings in one place.
Security commentary
Building the Means to Stay in Control
Design practical control boundaries for AI agents before their workflows become difficult to reverse.
Control should describe an action
Saying that an AI system is supervised leaves several questions unanswered. Who can authorise a particular operation? Which account will execute it? Can it be interrupted? What evidence will show whether it succeeded? A useful control model answers these questions for each sensitive capability. It describes concrete authority and observable behaviour, rather than relying on a general promise that a person remains in the loop.
Begin with one important workflow, such as granting access to a workspace or deploying a service. Write down the requested outcome and the operations that can produce it. Separate the agent's ability to propose a change from the service identity that has permission to apply it.
Make delegated authority narrow and temporary
A summarisation task rarely needs write access to the source system. A test run usually does not need the same credentials as a production deployment. Use distinct identities and credentials that are scoped to their actual work. Where possible, tie access to a short-lived job or session, with an owner and an expiry. Revocation should be an operational action that can be performed without asking the agent to cooperate.
Review compound workflows as well as individual tools. An agent may combine a harmless read with a powerful external write. A permission model that checks only whether each tool is generally available can miss the risk created by moving data between them. Include the destination and data sensitivity in the decision.
Design interruption and recovery together
A stop button has limited value if it only prevents the next model response while a background job continues modifying systems. Track active operations and propagate cancellation to the components that actually execute them. Define what cancellation can and cannot undo. A published message, a completed payment and a staged file change have different recovery properties, even if the same assistant initiated all three.
Prefer changes that can be inspected before they are applied, and preserve enough prior state to reverse routine configuration edits. For operations that cannot be reversed, require a more explicit decision at the execution boundary. The interface should state the real consequence, not bury it in a generic approval prompt.
Use records that survive the conversation
Keep an event trail containing the initiating request, selected account, approved parameters, tool action and returned result. Protect the log from modification by the same worker being evaluated. A reviewer should be able to distinguish a proposed operation from an attempted request and a confirmed effect. When the result is ambiguous, preserve that ambiguity rather than replacing it with a reassuring summary.
Exercise the controls through routine drills: revoke an agent's credential, cancel an active job, restore a previous configuration and investigate a deliberately failed action. These tests reveal whether the control exists in the execution path or only in documentation. Staying in control is an engineering property that can be demonstrated repeatedly, with limitations visible to the people relying on it.
