AI agents now hold real credentials to your systems. Most of them are barely governed.
Anthropic's Model Context Protocol (MCP) started life as a connector and quietly turned into the default way AI agents talk to software. That shift matters more than it sounds. An agent that can read a Jira board, open a cloud console, query a database, and push a commit is no longer a chatbot. It is a privileged actor inside your environment, and it makes decisions that are non-deterministic by design.
The industry knows the exposure is growing. In late August, OpenAI published an open letter signed by 116 companies, Anthropic among them, warning that AI-enabled cyberattacks will become "far more widespread and sophisticated" and calling for a coordinated defensive push. Entrust's Anudeep Parhar put the operational version of the same worry more bluntly: AI tools are advancing faster than the infrastructure built to control them. In our own engagements across banking, telecom, and critical national infrastructure, that gap is exactly where we keep finding problems. The agent gets deployed in a sprint. The controls around it get deferred to "later."
This article is about closing that gap with architecture you can actually implement, not policy slideware. If your organisation is piloting AI agents, wiring up MCP servers, or letting an autonomous assistant touch production, these are the controls we put in place before we sign off on a deployment.
What changed in the threat model
A traditional application account does what its code tells it to. You can read the code, trace the calls, and reason about the worst case. An AI agent breaks that assumption in three ways, and each one has a security consequence.
First, it is non-deterministic. The same prompt and the same tools can produce different tool calls on two runs, because the model, the system prompt, and the connected tools all change without warning. You cannot fully enumerate its behaviour ahead of time, so you have to constrain it at runtime instead.
Second, it takes untrusted input and turns it into actions. A support ticket, a web page, a PDF, an email, all of these can carry instructions that the model may follow. Prompt injection is not a theoretical edge case. It is the SQL injection of this decade, and the attack surface is every piece of content an agent reads.
Third, it usually runs with standing, over-broad credentials. The fastest way to get an agent working is to hand it a long-lived API key with wide scope. That is also the fastest way to hand an attacker the keys to everything the agent can reach. Ross McKerchar, CISO at Sophos, has pointed out that AI is already helping ransomware crews move faster; a compromised agent with broad access is precisely the kind of shortcut those crews are looking for.
Put those together and the picture is clear. An AI agent is a new class of privileged, semi-autonomous identity that acts on untrusted input. It deserves the same seriousness you would give a new admin account, and then some.
Treat every agent as an identity, not a feature
The single most useful mental model we bring to these projects: an agent is an identity. Give it its own service principal, not a human's credentials and not a shared team key. Once it has a distinct identity, everything else in your ISO 27001 and NIST CSF programme applies to it in the normal way. You can scope it, rotate it, monitor it, and revoke it.
Concretely, that means short-lived credentials issued through your existing identity provider, tokens scoped to the minimum set of actions the agent's job actually requires, and no shared secrets across agents. If an agent only needs to read from one storage bucket and write to one queue, its token should permit exactly that and nothing else. When we run least-privilege reviews, the token an agent was shipped with is almost always ten times broader than the task in front of it.
The CIS Benchmarks give you a concrete baseline for the underlying accounts and cloud roles. Map the agent's identity into the same access-review cadence you use for staff. An agent that has not been used in 30 days should trip the same dormant-account alert a departed employee would.
Put a policy layer in front of the tools
MCP makes it trivial to connect an agent to a tool. That convenience is the risk. The fix is to stop letting agents call sensitive tools directly and route those calls through a gateway you control.
An MCP gateway or tool broker sits between the model and the real systems. It enforces an allow-list of permitted tools, applies per-tool argument validation, and holds the actual credentials so the model never sees them. High-impact actions, deleting data, moving money, changing firewall rules, spinning up infrastructure, get a policy that requires either a second automated check or a human approval before they execute. This is the practical answer to the governance gaps Gartner keeps flagging when it asks "more agents, more problems?" Orchestration overlap and ungoverned tool access are where most agent programmes quietly lose control.
The gateway is also where you enforce rate limits and spend caps. An agent stuck in a loop should hit a wall long before it drains an API budget or hammers a production database. We treat those limits as safety controls, not billing hygiene.
Contain the blast radius
Assume any given agent can be compromised or manipulated, and design so that when it is, the damage stays local. This is standard segmentation thinking applied to a new kind of workload.
Run agents in isolated execution environments with tightly controlled egress. An agent that only needs to reach two internal APIs has no business making arbitrary outbound calls to the internet, and egress filtering is what stops a manipulated agent from exfiltrating data or pulling down a second-stage payload. For workloads touching regulated or highly sensitive data, we increasingly recommend running the model itself on-premises or in an air-gapped enclave. Keeping inference and the sensitive corpus inside your own boundary removes an entire category of third-party exposure, and for some of our compliance-driven clients it is the only architecture that passes review.
Network segmentation between agents matters too. A coding agent, a customer-support agent, and a finance agent should not share a trust zone. If one is subverted, the others should be unreachable.
Assume prompt injection and validate both ends
Because agents act on untrusted input, you have to treat their inputs and outputs the way you treat any untrusted data crossing a boundary. On the way in, separate instructions from data wherever the framework allows it, and be wary of content pulled from the open web or user submissions. On the way out, validate tool arguments against a strict schema before they execute. An agent asking to run rm -rf or to widen an IAM policy should be caught by a deterministic check, not by hoping the model behaves.
Content provenance helps. Tagging where a piece of context came from, and lowering the trust you place on externally sourced content, reduces the chance that a poisoned document turns into a real action. None of this makes injection impossible. It makes a single successful injection insufficient to cause harm, which is the realistic goal.
Log every action and actually watch it
If an agent can take an action, that action needs to land in your logs with the agent's identity, the tool it called, the arguments, and the outcome. Feed that stream into your SIEM alongside everything else and build detections for the behaviour that matters: an agent calling a tool it has never used, a spike in tool calls, access to data outside its normal pattern, or repeated approval requests for high-risk actions.
This is where the market trend and the practitioner reality meet. IDC's 2024 review of China's IT security software market, titled "All in AI," found the sector consolidating hard around AI and Agentic AI, with vendors pushing platform-based approaches like XDR and unified security management and the whole defensive posture shifting from passive to proactive. The direction is right. But a proactive posture is a capability, not a product you buy. The telemetry from your agents has to be wired into detection and response that a real SOC operates, or the platform is just another dashboard nobody reads at 2am.
How an AI agent identity differs from a normal application account
The table below summarises what changes when the privileged actor is an agent rather than a conventional service account. The controls are familiar. The emphasis shifts.
DimensionTraditional service accountAI agent identity
Behaviour
Deterministic, defined by code
Non-deterministic, shaped by model, prompt, and tools
Inputs
Structured, validated by the application
Untrusted natural-language content, including from the open web
Credentials
Scoped, often long-lived
Must be short-lived and narrowly scoped, brokered away from the model
Tool access
Fixed integration points
Dynamic via MCP; must be allow-listed through a gateway
Primary threat
Credential theft, code vulnerabilities
Prompt injection, over-broad scope, unintended actions
Detection basis
Known-good code paths
Behavioural baselines and anomaly detection in the SIEM
Approval for high-risk actions
Rarely needed
Required, enforced at the gateway
A checklist before you put an agent in production
This is the short version of the gate we apply. If an agent deployment cannot answer yes to each of these, it is not ready.
- The agent has its own identity in your identity provider, with no shared or human credentials.
- Its tokens are short-lived and scoped to the minimum actions its task requires, reviewed against least privilege.
- All sensitive tool calls route through a gateway that holds the credentials and enforces an allow-list.
- High-risk actions require a second check or human approval before they execute.
- The agent runs in an isolated environment with controlled egress; sensitive-data workloads run on-premises or air-gapped where required.
- Tool arguments are validated against a strict schema, and externally sourced content is treated as low-trust.
- Every action is logged with full context and streamed to the SIEM, with detections for anomalous tool use.
- Rate limits and spend caps are in place as safety controls.
- The agent's identity is in your access-review and dormant-account processes.
- There is a documented way to revoke the agent's access immediately, and someone has tested it.
Work through that list and you are mapping directly onto the control families in NIST CSF and ISO 27001. Agentic AI does not need a brand-new security framework. It needs the frameworks you already run, applied to a workload that moves faster and reasons for itself.
Where this is heading
Agents are about to reach further than software. Anthropic's Model Hardware Standard, released in research preview, extends the same connect-and-operate pattern to physical machines, from lab instruments to assembly lines. The moment an agent can drive hardware, the blast radius stops being digital. The controls in this article, identity, a policy gateway, containment, validation, and monitoring, are the same ones you will want in place before that transition arrives, which for many operators is a matter of quarters, not years.
The organisations that will handle this well are not the ones that buy the most AI security tooling. They are the ones that treat every agent as a governed identity from day one and wire it into the security operations they already trust.
How Aydahwa Enterprise Can Help
We help organisations across the UAE and wider GCC deploy AI agents and cloud-native workloads without giving up control of their environment. Our work spans identity and least-privilege design, MCP and tool-gateway architecture, network segmentation and egress control, on-premises and air-gapped deployment for regulated data, and SOC and SIEM integration so that agent activity is monitored the way every other privileged action is. We anchor all of it to the standards your auditors expect, including ISO 27001, NIST CSF, CIS Benchmarks, PCI-DSS, and SOC 2.
If you are piloting agentic AI or scaling it, our cybersecurity services and cloud security and migration teams can review your architecture and close the control gaps before they become incidents, with day-to-day operations backed by our managed IT support. To gauge where you stand right now, 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 map the controls to your environment.
