The August 6 agenda for Black Hat USA 2026 included several sessions about security for artificial intelligence agents. The topics were practical: guardrails, red teaming, and isolated environments that protect credentials, data, and infrastructure.
That concern is reasonable. Coding agents can already read repositories, edit files, and run commands. Giving them unrestricted production access greatly expands the damage that one mistaken instruction can cause.
An agent can make real changes
A chatbot returns an answer. An agent can also act on the system. It may install a dependency, query a service, or change configuration.
Claude Code and OpenCode let people review permissions before actions run. Even so, after several correct answers it becomes easy to approve everything automatically.
The risk does not require malicious AI. A mistyped variable can point to the wrong environment. An overly broad command can delete data. A file containing secrets can end up in the context sent to a provider.
How to limit access
I would start with an isolated environment, temporary credentials, and test data. The agent should see only the files and services required to complete the task.
When production access is necessary, permission can be limited to one specific action and a short period. It is also useful to log executed commands and keep a way to reverse every change.
The approval screen should explain what will happen. Knowing that an agent wants to “use a tool” is not enough; we need to see the command, the destination, and the affected files.
Security is defined before the agent starts
Limits work best when they are part of the workflow. The agent prepares a change, tests check its behavior, a person approves it, and the deployment retains a rollback path.
This process does not prevent teams from benefiting from AI. It prevents a quick task from ending with permissions nobody remembers granting.
What I would change today
I would review which agents can read production variables, deploy, or query customer data. If one session can do all three, I would separate those permissions.
I would also use different credentials for each project and environment. If one key is exposed, the scope of the problem will be smaller.
Black Hat brought these topics forward because agents are already part of everyday work. Their access should grow gradually and only when there is a clear reason.
Useful, or do you disagree?
Comments
What do you think?
There are no approved comments yet.