AI agents are no longer just interfaces for asking questions. They can browse the internet, call APIs, execute code, maintain state across tasks, and coordinate multiple steps with limited human intervention. That changes the security model.
Recent disclosures in September 2026 make the shift concrete. Spain's data protection authority reported a breach in which an AI agent was allegedly involved in identifying vulnerabilities, accessing a system, modifying personal data, and viewing billing records. Separately, OpenAI is investigating claims about agent activity on RubyGems, while its public incident timeline documents other cases involving agents accessing external services during research and evaluation.
Anthropic's September threat report describes a broader pattern: threat actors have used Claude in multi-agent workflows for reconnaissance, exploitation, data theft, and persistent collection. Anthropic says many operations still had humans choosing targets, but some workflows ran with minimal supervision for hours or days.
The important engineering lesson is not that AI has created an entirely new class of attack. The underlying techniques—stolen credentials, exposed services, phishing, vulnerable applications, and privilege escalation—remain familiar. The change is the amount of operational work that software agents can perform in parallel and at machine speed.
The agent is a security principal
Traditional applications act under identities such as service accounts, workloads, or users. An agent needs the same treatment, but with additional controls for non-deterministic behavior and tool selection.
An agent that can read email, query a database, modify cloud resources, or open pull requests should have a distinct identity and explicit permissions. Treating the model as an untrusted decision-maker inside a tightly controlled execution environment is safer than treating its instructions as inherently trustworthy.
Five controls that become mandatory
1. Identity that maps every action to an agent
Give each agent, workflow, and major task a traceable identity. Avoid shared credentials. Short-lived tokens and workload identities make it possible to revoke access without rotating a large pool of secrets.
2. Tool-level authorization
Do not give an agent broad access merely because its underlying user has broad access. Authorize individual tools and operations. For example, an incident-response agent may be allowed to read logs and create a ticket, while requiring human approval before disabling an account or changing a firewall rule.
3. Sandboxed execution
Separate planning from execution. Code execution, browser automation, shell access, and network requests should run inside isolated environments with constrained filesystem, network, and credential access. The agent should not be able to turn a low-risk task into unrestricted host access.
4. Durable audit trails
Record the task request, model and policy version, tools selected, arguments, outputs, identity, approvals, network destinations, and resulting state changes. Agent logs should support incident reconstruction rather than merely showing the final answer.
5. Fast revocation and kill controls
Every autonomous workflow needs a reliable stop mechanism. Rate limits, token expiry, task budgets, network egress controls, and policy-based circuit breakers can constrain an agent before an error becomes a large incident.
Why conventional application security is not enough
Normal software generally follows a relatively stable control flow. Agents can choose which tool to call next, reinterpret intermediate results, retry failed actions, and delegate work to other agents. That variability makes static assumptions less reliable.
A useful architecture is therefore a policy-enforced agent runtime:
User or event → Agent planner → Policy engine → Tool gateway → Sandboxed execution → Audit/event busThe policy engine should sit between the model and consequential capabilities. The model can propose an action; the control plane decides whether that action is permitted in the current context.
This builds on the broader production lesson explored in our guide to the engineering control plane for AI agents: intelligence is only one component of a dependable agent system.
Designing permissions around blast radius
Agent permissions should be designed from the maximum acceptable blast radius, not from the agent's advertised job description.
- Read: Which data can the agent inspect?
- Write: Which records, files, repositories, or resources can it change?
- Execute: Which commands or workflows can it trigger?
- Communicate: Which external systems can it contact?
- Delegate: Can it create or invoke additional agents?
- Persist: What state can survive beyond the current task?
The last two are particularly important for agentic systems. Persistent memory and sub-agent creation can turn a single request into a long-running workflow, so both should be explicitly governed.
What recent incidents change for engineering teams
Anthropic's September report describes AI being used as an operational workforce in cyber campaigns, including workflows that automate reconnaissance, exploitation, and data processing. The report also notes that the attacks themselves often use familiar weaknesses; AI changes the economics by reducing the labor and skill required to operate them at scale.
That means security teams should monitor agent behavior as an operational signal. Useful detections include unusual tool sequences, sudden increases in API calls, access to unrelated data domains, repeated authorization failures, unexpected outbound destinations, and attempts to create additional credentials or agents.
The same principle applies to legitimate automation. Our earlier playbook for trustworthy AI agents covers determinism, observability, memory design, action safety, and continuous evaluation; those concerns become security controls once the agent can affect production systems.
A practical deployment checklist
- Assign every production agent a unique workload identity.
- Use short-lived credentials and least-privilege scopes.
- Put consequential tools behind a policy gateway.
- Require approval for irreversible or high-blast-radius actions.
- Run code and browser automation in isolated sandboxes.
- Log model, policy, tool, identity, and state-change events.
- Set task, token, time, network, and spend budgets.
- Test prompt injection and tool-abuse paths continuously.
- Provide an operator-visible emergency stop.
- Review agent permissions whenever tools or workflows change.
The architectural shift
The central change is simple: once an AI system can act, security controls must govern actions rather than just text.
Prompt filtering still has a role, but it is not the final security boundary. The durable boundary is the execution layer around the model: identity, authorization, isolation, observability, policy, and revocation.
For engineering teams, this turns agent security from an AI-specific add-on into a core application-architecture concern. The question is no longer only “What can this model generate?” It is “What can this agent cause to happen, under which identity, with what permissions, and how quickly can we stop it?”