Posts

Featured Post

An Agent Audit Trail Should Read Like a Timeline

Image
A final message saying “task completed” is not an audit trail. It tells you what the agent wants you to believe happened. It doesn’t show which identity acted, what authority it had, which policy was applied, or why a tool call was allowed. That distinction matters when the result looks correct. Reconstruct the decision, not just the outcome An agent rarely performs one action. It interprets a request, selects an identity, checks available authority, chooses tools, applies policy, and produces an outcome. If the record stores only the final response, the important evidence is already gone. A useful audit trail should let an engineer or reviewer answer: What request started the run? Which agent identity handled it? What authority was delegated? Which policies were evaluated? Which tools did the agent consider and call? Where did an approval happen, or fail to happen? What did each action return? How did the run end? This is a timeline, not a transcript dump. The differ...
Read more

A Valid Agent Plan Can Become an Invalid Action

Image
An agent can start with permission to draft a production change and still have no permission to deploy it. That sounds obvious. In practice, many authorization designs treat the agent’s initial task as the security boundary. Once approved, the agent is free to discover data, call tools, and adjust its plan. That’s where control weakens. A runtime decision should follow the action, not just the task description. Consider an agent asked to prepare a production configuration change. At the start, the request may look safe: The user is identified. The agent is assigned a drafting task. The target system is known. The expected output is a proposed change. The agent reads configuration data, checks deployment status, discovers that the change affects a wider set of services, and produces a deployment command. The agent’s plan has changed. The final action is no longer “draft a change.” It’s “apply a change to production.” That should be a new authorization decision. The policy...
Read more

Authorization Is a Runtime Decision, Not a One-Time Permission

Image
An AI agent shouldn’t receive permanent permission just because its initial task looked safe. Plans Change During Execution Agents rarely follow a fixed path. They retrieve new information, select tools, update their plan, and decide what to do next. Each step can change the risk of the action that follows. A request to “prepare a production change” might begin as a low-risk drafting task. It becomes materially different when the agent discovers a live system, accesses sensitive data, or proposes an action that affects production. That change deserves a new policy decision. Evaluate the Full Context A useful authorization decision needs more than the requested action. Evaluate: The agent making the request The user behind the agent The tool being called The resource being accessed The current task and execution context The action's potential effect The same agent may be allowed to read a configuration file but blocked from changing it. The same user may be permitte...
Read more

The Dangerous Moment for an AI Agent Is When Its Task Changes

Image
Most AI agent permissions are approved at the start of a task and forgotten when the task expands. That’s where the control breaks. A support-summary agent may begin with permission to read selected customer records and produce an internal summary. The original request is narrow. The authority makes sense. Then the workflow changes. The agent is asked to include a spreadsheet export, update a ticket, or investigate a related account. The task sounds like a small extension, but the required actions are different. If the agent keeps its original access without a new check, the system is treating a new task as if it were the old one. That’s a design mistake. Authority should follow the task An agent’s permission should be bounded by four questions: What task is it performing? How long should that authority remain active? Which resources can it access? Which actions can it take? For the support-summary example, the boundary might be: Read selected support records For one h...
Read more

AI Agent Permissions Should Expire Like Temporary Access

Image
An AI agent shouldn’t keep access after the task that justified it is finished. Start With the Task Permissions should begin with a clear job, not a broad role. Before an agent can access a system, define: What task it needs to complete Which records or resources it can read Which actions it may take Which actions are out of bounds A support-summary agent may need to read selected customer records. It doesn’t need permission to export those records, change account details, or send messages. The narrower the task, the easier it is to review the agent’s actions. Set a Boundary Around Authority Access should have limits beyond the task itself. Set: An expiry time A resource boundary An action boundary A clear owner for the permission For example, an agent could read selected support records for one hour to prepare an internal summary. During that window, it cannot modify the records or export the underlying data. That gives the agent enough authority to work without ...
Read more