The question every security lead is now asking
At Fal.Con Europe 2025, CrowdStrike put a name to something that had been circling boardrooms for a year: Charlotte Agentic SOAR, an orchestration layer that coordinates AI agents across prevention, detection, investigation and response, with analysts steering them through natural language and drag-and-drop instead of code. The framing in the trade press was blunt. Can AI agents replace security analysts? A few weeks later Anthropic reported that its Claude models had helped identify and disrupt what it described as the first large-scale cyber espionage campaign run largely by AI agents, with little human involvement on the attacker's side.
So the technology now cuts both ways. Defenders are wiring agents into the SOC, and attackers are doing exactly the same thing. We get asked about this on almost every engagement now, usually in some version of "should we be using these, and how do we do it without creating a new hole?" This article is our working answer. It is not a product pitch and it is not a warning to stay away. It is how we actually deploy agentic automation for clients in banking, telecom and critical infrastructure, where a bad automated action has consequences well beyond a noisy alert.
What an "AI agent" actually means inside a SOC
The term gets stretched to cover everything, so it helps to be precise. A plain automation script follows fixed logic: if this alert fires, run that playbook. A large language model on its own generates text. An agent sits between the two. It takes a goal ("triage this alert"), decides which tools to call, calls them, reads the results, and decides what to do next, looping until it thinks the goal is met. In a security context those tools are your SIEM queries, your EDR console, your ticketing system, your threat-intel lookups, sometimes your firewall or identity provider.
That autonomy is the whole point, and it is also the whole risk. A script can only do what you wrote. An agent can chain actions you never explicitly sequenced, which is powerful when it saves an analyst forty minutes of pivoting between consoles, and dangerous when it decides to isolate a domain controller at 3am because a detection rule was too broad.
Where agents genuinely earn their place
The strongest case today is Tier 1 work: the repetitive, high-volume triage that burns out analysts and where most alerts turn out to be benign. An agent that enriches an alert with asset context, user history, geolocation and recent threat intel, then writes a plain-language summary with a recommended disposition, can take a queue that used to eat a shift and cut it to a review pass. We have seen this collapse mean-time-to-triage on commodity alerts without touching the harder investigations at all.
Detection engineering is another good fit. Agents are surprisingly effective at drafting and tuning detection logic, translating a MITRE ATT&CK technique into a candidate SIEM rule, or proposing exceptions for a known false-positive pattern. A human still reviews and commits the rule, but the blank-page problem goes away. The same applies to first-draft incident timelines, phishing-report parsing, and pulling together the evidence for a compliance ticket.
On the cloud side, the model that Google Cloud and Wiz have pushed points at where this is heading: continuous, agent-assisted scanning that surfaces real attack paths across a multi-cloud estate in minutes rather than a quarterly assessment. For an organisation running workloads across AWS, Azure and GCP, that shift from periodic audit to always-on posture checking is the part worth paying attention to.
Where they cause trouble
Three failure modes come up again and again, and none of them are exotic.
The first is over-broad action. Give an agent write access to your EDR and a fuzzy instruction, and it will eventually take a containment action on the wrong host. The blast radius of an agent is the sum of every permission you handed it, and agents are very good at finding the full extent of what they are allowed to do.
The second is prompt injection, and this is the one people underestimate. An agent that reads alert data, email bodies, ticket comments or web pages is reading attacker-controllable text. A crafted string buried in a phishing email or a log field can hijack the agent's instructions. The researcher-built Morris II worm made this concrete: a zero-click, self-replicating "malware" that spreads purely through adversarial prompts that manipulate generative AI, no traditional payload required. It was a lab demonstration, but the mechanism is real, and any agent that ingests untrusted input is exposed to a version of it.
The third is confident fabrication. An agent will produce a fluent, well-structured incident summary that is wrong, and a tired analyst at the end of a shift will approve it because it reads like every other summary. Fluency is not accuracy, and in a SOC that gap gets people to sign off on the wrong conclusion.
The uncomfortable half: attackers have agents too
Every capability that helps a defender helps an attacker with fewer scruples. The Anthropic espionage case is the headline example, but the day-to-day reality is more mundane and more relevant to most businesses: agents that write convincing spear-phishing at scale, probe exposed services and adapt, or generate malware variants faster than signature-based tools can keep up. Gartner has already named Palo Alto Networks the front-runner in AI security precisely because buyers now expect their defensive stack to counter machine-speed offence.
The practical takeaway is not to panic. It is that detection and response timelines built around human attacker tempo are being compressed, and a SOC that still measures response in hours is going to be tested by adversaries measuring it in seconds. That is an argument for defensive automation, deployed carefully, rather than against it.
Analyst versus agent: who should own what
We find it clearer to split the work by decision reversibility than by difficulty. Reversible, high-volume, low-consequence work is a good candidate for agents. Irreversible or high-consequence decisions stay with people.
TaskBetter suited toWhy
Alert enrichment and first-pass triage
Agent
High volume, reversible, most alerts are benign
Drafting detection rules and timelines
Agent, human commits
Speeds the work; a person still owns the decision
Deciding to isolate a production host
Human
High business impact, hard to undo cleanly
Confirming a genuine incident and its scope
Human
Accountability and judgement under ambiguity
Threat-intel gathering and correlation
Agent
Tedious, wide-ranging, low risk in isolation
Communicating with regulators or the board
Human
Legal and reputational weight, no room for fabrication
How we deploy agents without handing over the keys
The single most useful idea we bring to these projects is tiered autonomy. Rather than asking "do we trust the agent," which has no good answer, you decide per action how much the agent may do on its own, and you raise that ceiling only as the agent earns it against real traffic. We think of it as four tiers.
Tier 0 is observe and suggest. The agent reads and recommends, and a human performs every action. This is where every new agent starts, and it is where you learn whether its recommendations are any good before it can touch anything. Tier 1 lets the agent take reversible, low-impact actions on its own, enrichment, tagging, opening a ticket. Tier 2 lets it propose a response action, isolating a host, disabling an account, but a named human approves before it executes. Tier 3 is narrow auto-remediation: a small, explicitly pre-approved set of scenarios where the agent acts on its own, always with full logging and a tested rollback. Anything outside that set escalates to a person. Most of our clients run production agents at Tier 1 for triage and Tier 2 for response, and are in no hurry to move past that.
Around whichever tier you choose, the same controls apply. Give the agent its own identity, not a shared or human one, so its actions are attributable. Scope its permissions to exactly what its tier needs and no more. Log every tool call it makes as an immutable audit trail. Treat all data it ingests as untrusted, and keep a human approval gate on anything that changes state in production. None of this is new security thinking. It is least privilege, segregation of duties and non-repudiation applied to a non-human actor.
A deployment checklist
- Start every agent at Tier 0 and require it to prove its recommendation quality against live alerts before you raise its autonomy.
- Issue the agent a dedicated service identity with its own credentials, scoped to a single tier of permissions.
- Write down, explicitly, the small set of actions the agent may take without human approval, and treat everything else as escalate-to-human by default.
- Log every tool call and decision to a tamper-evident store, and make those logs reviewable by your SOC lead, not just by the vendor.
- Assume prompt injection. Sandbox the tools an agent can reach, and never let untrusted input reach an agent that holds destructive permissions.
- Keep a tested rollback for any action the agent can take automatically. If you cannot cleanly undo it, it does not belong at Tier 3.
- Review the agent's actions on the same cadence you review analyst work, and pull its autonomy down the moment its error rate drifts.
- Include the agent in your incident response plan as a component that can itself fail or be manipulated.
Mapping this to the frameworks you already report against
None of this requires a new compliance programme. Tiered autonomy and scoped identities map cleanly onto controls you are almost certainly already assessed against. Under ISO 27001 an AI agent is an asset and an access-control subject, and Annex A controls on access management, logging and segregation of duties apply to it directly. Under the NIST Cybersecurity Framework, agents touch Detect and Respond, and the governance expectations added in CSF 2.0 are a good prompt to write down who owns the agent and who is accountable when it acts. CIS Controls on audit-log management and controlled use of administrative privileges translate almost word for word to non-human actors. If your organisation handles cardholder data, PCI DSS requirements on access control and logging cover automated agents the same way they cover any other account with access to the environment.
The point we make to boards is that agentic AI in the SOC is not a reason to rewrite your control framework. It is a new kind of privileged account, and your existing frameworks already know how to govern privileged accounts. The work is in the discipline of applying them, not in inventing something new.
How Aydahwa Enterprise can help
We help organisations across the UAE and wider GCC put automation into their security operations without trading away control. That work usually starts with an honest look at where you are today: what your SOC actually spends its time on, which tasks are safe to hand to an agent, and what your current tooling and permissions would allow an agent to do if something went wrong. From there we design the tier model, the identities, the logging and the approval gates, and we map the whole thing back to the standards you already report against, whether that is ISO 27001, NIST CSF, CIS Controls or PCI DSS.
If you want to gauge your own readiness before talking to anyone, our free cybersecurity self-assessment and readiness checklist are a sensible starting point. You can read more about how we approach cybersecurity and cloud security and migration, or how our managed IT and support services fit around an in-house team. When you are ready to talk specifics, get in touch and we will walk through it with you.
