Agents added a new attack surface, a system that takes natural-language instructions and acts on its own, so security engineering expanded from securing code to securing autonomous decisions. Prompt injection, tool abuse, and data exfiltration are the new baseline, and accountability for the agent's permission boundary rests with the security engineer.
Security engineering had a known map. Validate inputs, manage secrets, patch dependencies, enforce least privilege, audit access, and assume any input could be hostile. The threats evolved, but the surface was understood.
Agents added a surface that did not exist before: a system that takes natural-language instructions, decides on its own which tools to call, and acts. Every one of those properties is an attack vector. An attacker who can influence the input can try to rewrite the agent's instructions. An agent with broad tool access is a broad blast radius waiting for the wrong prompt.
From securing code to securing decisions
In the AIDLC method, this work lives in the Harden phase, and it is squarely the security engineer's. The threats are specific. Prompt injection that smuggles instructions past the system prompt. Tool abuse where a manipulated agent takes a destructive action it was technically allowed to take. Data exfiltration where sensitive context leaks through an output. Over-broad permissions that turn a small compromise into a large one.
Defending against these is not a checklist bolted on at the end. It is permission boundaries designed so the agent can only ever do safe things, injection defenses on every input path, PII redaction before data reaches the model, and audit logs that record every decision the agent made. When residency, PDPL, or DIFC compliance demand it, the model itself runs on private infrastructure so the data never leaves the network.
Accountability did not move
Here is what did not change: when an agent does something harmful, the security engineer answers for it. Autonomy does not dilute accountability, it concentrates it. The person who designed the agent's permission boundary owns the consequences of that boundary being too wide.
That is why Harden is a named phase with real outputs, not an afterthought. Guardrails, redaction, audit logging, and a residency-compliant deployment are the deliverables, and they are what let an autonomous system run in a regulated environment at all.
If your team gave an agent tool access without designing the permission boundary and the injection defenses first, you have shipped an attack surface, not a feature.
The security engineers who win
They threat-model the agent's autonomy, not just its code. They make the permission boundary the tightest thing in the system. They treat audit logs and redaction as required, not optional. And they measure their work in actions the agent could never have been tricked into taking.
Gave an agent tool access before designing its security boundary?
Most AI projects stall because nobody on the team knows how to design agents, manage token budgets, or wire production evals. I build that layer for B2B companies so the feature actually ships and keeps shipping.
Senior engineer turned AI specialist. React, Next.js, AWS, agent orchestration.
Direct collaboration across UAE, Europe, and US time zones.
Discovery, role design, MCP integration, evals, and production deployment.
If you want an agentic system hardened for production and regulated environments, book a discovery call and we will scope the threat model.