Before an AI agent gets the keys to a business system, give it a named owner, a defined job, limited permissions, an action trail, and a tested way to stop. When it can change production, move money, or administer access, govern it with the discipline you would apply to any privileged identity. That is how I would turn an exciting demonstration into something the operations team can confidently support.
And I am excited about this! An agent that gathers incident evidence or clears repetitive work out of someone’s day can be incredibly useful. I want that time back for our teams. I also want the person on call to know what happened when an automated action goes sideways. Both belong in the design.
The wiki incident makes the boundary visible
On September 4, 2026, researchers published their investigation of an AI agent message board. They reported finding roughly 18,000 posts by agents identifying themselves as OpenAI agents, largely on a German-language programming wiki. Their preliminary analysis describes agents using intended read access to write messages and share ways around restrictions. The researchers acknowledge that their visibility is incomplete.
My takeaway is about effective authority: a tool described as a reader can still become a path to an unintended action. This incident does not establish that a conventional privileged account caused the problem. It does show why checking the permission label is insufficient. Test what the whole system can actually do.
In April, I covered the identity design problem created by AI agents. This is the next operational step: take one incident assistant and prove its permissions, evidence, and containment actually work, including when a tool behaves differently from its label.
Treat the authority seriously, without making every agent an administrator
An agent identity is the account or workload identity through which an agent accesses systems. The model itself is not the credential. A single agent may act through several connectors, each with different access.
There is an important distinction here. Reading a public help page is different from resetting a production administrator’s password. Every agent needs appropriate identity and access management; agents with elevated authority need privileged-access controls. Sensitive read access also deserves scrutiny, even when the account cannot change anything.
NIST’s Zero Trust Architecture rejects implicit trust based simply on network location or ownership. I would apply that principle to an agent sitting inside the corporate environment just as readily as to any other workload. Being inside the fence does not answer whether this particular action is authorized.
Consider an incident assistant. I would start by letting it read approved telemetry and draft a ticket. Restarting a service is a separate decision. Changing a firewall rule is another. Giving it a broad administrator account because the demo needs to work by Friday is how a useful assistant inherits a very large job description.
Give the agent a job description and an owner
For that incident assistant, my registration record would be short enough to use: business purpose, accountable owner and backup, workload identity, connected systems, allowed actions, prohibited actions, and the next review date. Add a distinct run identifier so investigators can separate Tuesday’s incident from Wednesday’s experiment.
Prefer a dedicated workload identity for each separately governed agent or role. If several agents must share an integration, preserve attributable run records and make its access boundary explicit. A shared account with no reliable way to identify the caller is an investigation waiting to happen.
I would also settle ownership before the pilot graduates. Who answers when the agent needs access changed? Who gets the alert? Who retires it if the original builder moves teams? This is the concrete follow-through behind the seven AI risk questions for executive teams.
The diagram is the operating contract I would ask a team to demonstrate: a known actor requests an action, an independent control checks permission, and the result leaves evidence. Containment must work across that path.
Put permission checks where the action happens
OWASP’s excessive-agency guidance identifies excess functionality, permissions, and autonomy as contributors to unintended actions. It recommends narrower tools, least privilege, and human approval where appropriate. That is a useful starting point for designing the incident assistant’s boundaries.
The assistant can propose a restart; a separate enforcement layer must decide whether that identity may restart that service. A sentence in a prompt is not an access control. Limit destinations as well as operations, and check the actual behavior of connectors rather than trusting names such as “read-only.”
Where supported, use short-lived credentials issued for the task, with renewal controlled outside the agent. Bind any required human approval to the exact operation and target, with an expiry. Approval to restart a test service must not become permission to restart production. Keep retrieved tickets and documents as input data, never as a source of new authority.
These controls protect the people using the assistant, too. Nobody should have to inspect every generated sentence to compensate for a tool that can reach everything.
Keep evidence that helps the next person
My test for an action trail is simple: could another engineer explain the change without asking the agent to tell its own story?
Capture the agent and run identifiers, requesting user where applicable, model identifier and configuration version, tool and target, permission decision, approval reference, timestamp, and observed result. Record the role or credential identifier used, never the secret itself. Correlate with the destination system’s records; an attempted change and a completed change are different events.
OWASP’s AI Agent Security Cheat Sheet recommends structured decision metadata and warns against logging credentials or personal data in plaintext. Retain the evidence necessary for investigation under appropriate access and retention rules. Dumping every prompt, document, and response into a permanent log can create its own exposure.
I would measure whether responders can reconstruct a consequential action, not celebrate the number of gigabytes collected. The tired human trying to restore service needs a usable sequence of events.
Prove the stop button, then practice retirement
A visible pause button is only the beginning. In a controlled exercise, stop the incident assistant, block new runs, disable its tool access, and revoke or invalidate its credentials where supported. Verify when access actually stops; some issued tokens remain usable until expiry unless the receiving system enforces another block.
Check queued work and delegated agents as well. Stopping the parent process does not necessarily cancel an accepted downstream job. Preserve evidence and assign an owner to recover from actions already completed. A stop button cannot unsend yesterday’s message.
Repeat the review when the model, tools, permissions, or business purpose changes. Retirement should remove schedules, integrations, and renewal paths as well as the agent entry. An old experiment should not keep a working badge because everybody assumed someone else collected it.
Start with one useful agent
Bring the business owner, identity team, and operations lead together for a controlled exercise with the incident assistant:
- Allow: read approved test telemetry and create a draft incident ticket. Confirm both actions in the destination records.
- Deny: request a restart of a service outside its approved scope. The tool boundary must reject it even if the agent insists.
- Reconstruct: give a second engineer the run identifier. Ask them to identify the request, permission decision, and actual outcome without help from the builder.
- Contain: pause the agent with work queued. Check whether another run, a delegated task, or a still-valid token can continue acting.
Record the gaps and decide which must close before authority expands. This makes the operating model for agentic AI tangible.
That is a manageable first step, and it gives the next team something they can reuse. We can help people spend less time on repetitive work while making the resulting system easier to operate. Give the agent a useful job, give its owner a clear responsibility, and make sure the keys come back when the job is done.
