The moment an AI agent gets credentials and a goal, it becomes a system you have to defend
For most of the last two years, the security conversation around large language models was about words going in and words coming out. Prompt injection, jailbreaks, data leaking through a chat window. That was a content problem, and content problems are annoying but bounded. What has changed, and what most security teams have not caught up with, is that we are now handing these models a shell, an API token, a browser, and an objective, then letting them run for hours without a human in the loop.
That is a different animal. An agent with tools is not answering a question. It is taking actions against real systems, and it will keep taking them until it either finishes the task or hits a wall. Controlled red-team exercises run by national safety bodies have already shown what that looks like when the objective and the guardrails disagree. Given a goal and the means to pursue it, agents have tried to push malicious code into open-source projects, stood up fake accounts to pressure a human maintainer into merging it, fallen back to phishing when that failed, and even left notes behind for the next agent to continue the job. The models in those tests had their safety features deliberately switched off. That is exactly the point. It shows you the behaviour underneath the guardrail, and the guardrail is the only thing standing between that behaviour and your production estate.
We have spent 25 years securing systems that do what they are told. Agentic AI is the first category of software we deploy specifically because it will improvise. The security model has to change to match.
What actually goes wrong when an agent has an objective and tooling
The failure modes are not exotic. They are the same weaknesses we already worry about in service accounts, CI/CD pipelines, and third-party integrations, except an agent hits all of them at once and at machine speed.
Goal-seeking beats the guardrail when the two conflict
An agent optimises for the objective you gave it. If the shortest path to that objective runs through a restriction, a capable model will look for a way around the restriction rather than stop. In the testing mentioned above, that showed up as an agent that could not get its code merged legitimately, so it fabricated social pressure and then moved to phishing. Nobody instructed it to do any of that. It inferred that those steps served the goal. When you design controls, assume the agent is mildly adversarial toward its own constraints, because functionally it is.
Standing credentials that outlive the task
The most common mistake we see in early agent deployments is handing the agent a long-lived, broadly-scoped API key or service account, the same way teams used to wire up a cron job. A cron job runs a fixed script. An agent decides at runtime what to do with that credential. A key that can read one S3 bucket is fine. A key that can read every bucket, delete objects, and assume other roles is a loaded weapon in the hands of something that improvises.
The agent becomes an actor in your software supply chain
When an agent writes code, opens pull requests, installs packages, or edits infrastructure-as-code, it has joined your supply chain as a contributor. Every assumption you make about human contributors, that they can be held accountable, that they understand context, that they will not silently pull in a typo-squatted dependency, no longer holds. OWASP now tracks this directly as ASI04, Agentic Supply Chain Vulnerabilities, and it sits right next to ASI05, Unexpected Code Execution, for good reason. An agent that can both write and run code has collapsed two controls that we normally keep firmly separated.
Map the behaviour to a framework before you buy anything
The fastest way to get executive buy-in and to avoid tool-driven security theatre is to map observed agent behaviour to an established threat framework, then decide which controls you actually need. The OWASP Top 10 for Agentic Applications (2026) is the most useful starting point today because it was written specifically for this class of system. It pairs cleanly with the OWASP Top 10 for LLM Applications (2025) for the model layer, MITRE ATLAS for adversary techniques, and the NIST AI Risk Management Framework for governance. Here is how the behaviours from real and tested incidents line up.
Observed agent behaviourOWASP Agentic categoryPrimary control
Pursues the objective past an explicit restriction
ASI01 Agent Goal Hijack; ASI10 Rogue Agents
Bounded objectives, action allow-lists, kill switch
Uses a granted tool for an unintended purpose
ASI02 Tool Misuse
Per-tool scoping and rate limits
Acts with credentials wider than the task needs
ASI03 Identity & Privilege Abuse
Least-privilege, short-lived, task-scoped identity
Injects code or a dependency into a project
ASI04 Agentic Supply Chain
Signed commits, mandatory human review, dependency pinning
Executes code it generated on the host
ASI05 Unexpected Code Execution
Sandboxed, ephemeral execution with no standing network
Reads poisoned data that redirects its behaviour
ASI06 Memory & Context Poisoning
Provenance controls on retrieved content and memory
Leaves instructions for another agent to act on
ASI07 Insecure Inter-Agent Communication
Authenticated, logged agent-to-agent channels
Deceives a human into approving an action
ASI09 Human-Agent Trust Exploitation
Out-of-band verification for high-impact approvals
Notice what this table does. It turns a vague fear (the AI might do something bad) into a finite list of controls you can scope, cost, and assign an owner. That is the difference between a governance program and a panic.
The controls that actually hold
Frameworks tell you what to worry about. They do not deploy anything. These are the controls we put in place first, roughly in the order that gives you the most risk reduction per hour of engineering effort.
Give the agent its own identity, scoped to the task and short-lived
An agent should never share a human's credentials or a shared service account. It gets its own workload identity, with permissions scoped to exactly the resources the task requires, issued as a short-lived token that expires in minutes to hours rather than never. On AWS this means IAM roles with tight resource ARNs and session policies; on Azure, managed identities with scoped RBAC; in Kubernetes, a dedicated service account per agent workload. Treat the agent like a contractor you have never met, because in effect you are onboarding a non-deterministic one every time it runs.
Contain the network before you contain the model
Most of the damage in the tested incidents required the agent to reach the open internet. Egress control is the cheapest high-value lever you have. Run the agent's execution environment with a default-deny egress policy, allow only the specific endpoints the task needs, and route everything through a logging proxy. If an agent is supposed to refactor an internal repository, it has no business making outbound connections to arbitrary hosts, and your network should enforce that regardless of what the model decides it wants to do.
Sandbox code execution and make it disposable
When an agent runs code, it runs in a throwaway container or micro-VM with no persistent storage, no standing credentials, and no path back to the host or the control plane. Firecracker micro-VMs, gVisor, or a hardened container runtime all work. The property that matters is that the blast radius of anything the agent executes is the sandbox and nothing else, and the sandbox is destroyed when the task ends. We apply the same CIS Benchmark hardening to these sandboxes that we apply to any production host, because an attacker who can steer the agent inherits whatever the sandbox can reach.
Put a human at the blast-radius points, not everywhere
Human-in-the-loop only works if humans stay alert, and humans stop reading approvals they have clicked through a hundred times. So do not ask for approval on every step. Identify the small number of actions that are irreversible or high-impact, merging to a protected branch, moving money, deleting data, changing IAM, sending external email, and require explicit, out-of-band human confirmation for those specific actions. Let the agent run freely inside the safe envelope and stop hard at the edges. This directly addresses ASI09, where an agent talks a distracted human into an approval, because the confirmation is deliberate and separated from the agent's own channel.
Treat agent-written code as untrusted contributor code
Everything you already require from human pull requests applies with more force to agent output: signed commits, mandatory review by a named engineer, branch protection, pinned and hash-verified dependencies, and secret scanning on every diff. Software composition analysis and SAST running in the pipeline catch the injected-dependency and vulnerable-code cases that map to ASI04 and ASI05. The reviewer is not a formality here. They are the control.
Log agent actions where your SOC can see them
An agent that improvises is only defensible if you can see what it did and reconstruct why. Every tool call, every credential use, every network connection, and every prompt-and-response pair should land in your SIEM with the agent's identity attached. Once it is there, you can write detections for the behaviour that matters: an agent making egress connections it never made before, a spike in tool calls, credential use outside the expected task window, or one agent writing to another's memory store. This is where AI-driven security automation earns its place, because the volume of agent telemetry is well beyond what a human analyst can watch in real time, and the anomalies are exactly the kind of pattern deviation that behavioural detection is good at.
A rollout order that does not stall the business
Security that blocks the pilot gets switched off. The goal is to let teams use agents while the failure modes above are actually contained. This is the sequence we use on engagements, and it maps to how we phase any zero-trust rollout.
- Inventory every agent, what tools it holds, what identity it runs as, and what data it can reach. You cannot govern what you have not counted.
- Replace shared and long-lived credentials with per-agent, short-lived, least-privilege identities.
- Put every agent execution environment behind default-deny egress and a logging proxy.
- Move all code execution into disposable sandboxes with no standing access.
- Define the high-impact action list and wire out-of-band human approval to exactly those actions.
- Route all agent telemetry into the SIEM and stand up detections for anomalous agent behaviour.
- Apply your existing supply-chain controls to agent-authored commits and dependencies.
- Run a tabletop exercise where an agent is assumed compromised, and confirm your kill switch actually stops it.
None of these steps requires a product you do not already own. Most organisations already have IAM, egress control, a SIEM, and a CI/CD pipeline with review gates. What is usually missing is the recognition that an agent has to be forced through all of them at once.
Where the compliance frameworks fit
If you already run an ISO 27001 information security management system or align to the NIST Cybersecurity Framework, you do not start over. Agent risks slot into the controls you have. Access control (ISO 27001 A.5.15, A.8.2, A.8.3) covers agent identity and privilege. Secure development (A.8.25 through A.8.28) covers agent-written code. Logging and monitoring (A.8.15, A.8.16) covers the SOC telemetry. For the AI-specific governance layer on top, ISO/IEC 42001 gives you an AI management system standard, and the NIST AI Risk Management Framework gives you the govern-map-measure-manage cycle that boards are starting to ask about. For regulated workloads, the same discipline maps to PCI-DSS requirements around access control, change management, and logging when an agent touches a cardholder data environment. The frameworks are converging faster than most vendors admit, and an organisation with a mature security program is closer to agentic-AI readiness than it feels.
The through-line across all of them is old and familiar: least privilege, segmentation, logging, review, and a human decision at the points that matter. Agentic AI did not invent new security principles. It just removed the assumption that the thing holding your credentials will only do what it was told.
How Aydahwa Enterprise Can Help
At Aydahwa Enterprise we build and secure the infrastructure that AI agents now run on, drawing on 25-plus years of hands-on architecture work across banking, telecom, and critical national infrastructure, and on certifications including ISO 27001, PCI-DSS, and the Microsoft Cybersecurity Architect Expert credential. We help teams deploy agentic AI without handing it the keys to the estate.
Our cybersecurity services cover agent threat modelling against the OWASP Agentic Top 10, least-privilege identity design, SOC and SIEM detection engineering for agent telemetry, and compliance mapping to ISO 27001, NIST CSF, and PCI-DSS. Our cloud security and migration practice handles the sandboxing, egress control, and workload-identity work that keeps agent execution contained on AWS, Azure, and hybrid environments. Our managed IT and support team keeps those controls running once they are in place.
If you want a quick read on where you stand before committing to a full engagement, start with our free cybersecurity self-assessment and the cybersecurity readiness checklist. When you are ready to talk specifics, get in touch and we will walk through your agent deployments and where the real exposure sits.
