If an AI agent can act in real systems, its access should be part of the design.
Prompts still matter. Clear instructions help an agent understand the job, the rules, and what a good result looks like. But a sentence telling an agent to stay within bounds should not be the only thing keeping it away from a customer database, an email account, or a production website.
One concrete example appears in Anthropic's assessment of four cybersecurity-evaluation incidents. Claude models reached real third-party systems from environments that were supposed to be isolated. A shared configuration error left them connected to the open internet, and the models were running without the cyber safeguards used in released products. Those conditions matter when interpreting the report.
The report describes models disregarding or misinterpreting evidence that they were operating on the real internet, and taking harmful actions while pursuing the assigned task. My takeaway is that a workflow needs a technical limit on its reach even when its written instructions sound clear.
The same design question applies to ordinary business automations: does the access actually match the job?
An agent helping with marketing may need access to approved product information and a staging copy of the website. It does not need billing records or permission to email every contact. An agent organizing insurance-verification work may need specific patient and payer information. It should not inherit every credential available to the person who started the task. A reporting agent can often begin with read-only access.
Before giving an agent a real tool, I would define five things:
- What it can read.
- What it can change without asking.
- Which actions require a person to approve them.
- Which conditions require it to stop and hand the work back.
- What record it must leave so someone can review what happened.
Those decisions should be enforced outside the prompt whenever the system allows it. Use separate accounts and roles. Restrict network access. Keep destructive or external actions behind approval. Test the workflow with incomplete information, a broken integration, and a result that does not make sense.
GitHub's enterprise managed settings provide an example. Administrators can block specified commands, file operations, and network destinations, require fresh approval, or allow them. The exact enforcement depends on the supported client and configuration. When evaluating any agent platform, ask the provider to demonstrate that a blocked operation stays blocked when the agent tries it.
Permission controls do not make the agent's work correct. They limit what can happen when the work is wrong, incomplete, or based on a bad assumption. Review and measurement still matter.
When I look at a proposed automation, I want to see the job, the access, and the proof of completion together. If the agent needs more access later, that can be added after the earlier version produces consistent results. Responsibility should grow with evidence.
Start the next automation discussion with a concrete question: what is the smallest set of systems and actions this job actually requires? Give the agent that boundary, make the risky steps visible, and make sure the workflow knows when to stop.