NCSC’s Agentic AI Warning Is a Wake-Up Call But Observability Is Where The Real Test Begins

By Findlay Whitelaw, Field CISO, Exabeam

The National Cyber Security Centre’s (NCSC) on managing the cyber risk of agentic AI, published last week, is interim advice rather than formal guidance, the NCSC itself is candid that fuller standards are still to come.

But even in this early form, it lands on the right question: not whether an AI agent has legitimate access, but whether its behaviour, in practice, stays inside the boundaries the organisation intended.

That distinction is the section of the blog that will resonate hardest with security teams because it points straight at observability as the mechanism that turns ‘pull the plug’ from a slogan into something a SOC can actually do.

“NCSC’s guidance is a useful early signal, but the section that will land hardest with security teams is observability, ‘chain of thought traces,’ sandbox logs, immutable audit trails. That’s not a new problem, it’s the same problem SOC teams have always had: can you see what’s actually happening, and can you prove it after the fact? The difference is agentic AI multiplies the volume and speed of activity that needs watching. If you can’t correlate an agent’s actions with the rest of your security telemetry in near real time, the ‘pull the plug’ advice is theoretical, by the time a human notices, the agent’s already moved on. Treating agentic AI activity as a form of user identity that gets logged, monitored and investigated like any other account isn’t optional anymore; it’s the baseline.”

Two Baselines Not One

Part of what makes agentic AI hard to govern is that ‘expected behaviour’ is being asked to do two jobs at once. The first is the agent’s intended operating baseline: its defined purpose, permissions, authorised systems and decision boundaries, which the deploying team should own, with security helping set risk boundaries and monitoring requirements.

The second is its observed behavioural baseline: how it actually operates over time, established through telemetry rather than policy. A deviation from either is a signal to investigate, not automatic proof of something malicious or unsafe.

Conflating the two is how organisations end up either over-trusting an agent because it’s technically authorised, or panicking over behaviour that’s actually a normal, if unusual, way of doing the job it was given. Observed behaviour becoming normal should never, by itself, make it authorised, the behavioural baseline must remain anchored to the agent approved purpose and boundaries.

The Failure Mode Traditional Controls Are Least Prepared For

Of the three obvious failure modes; a compromised agent, a misconfigured one and one that’s fully authorised but doing something it shouldn’t, the third is the one that should worry security teams most, precisely because there’s no broken credential or failed access control to trip an alert.

The risk sits in the actions and their consequences, not in whether the agent was allowed to act in the first place. Publicly documented real-world incidents involving fully authorised agents are still relatively scarce, but that scarcity reflects reporting and recognition gaps more than rarity. Controlled agentic-misalignment testing from frontier labs already shows that agents with legitimate access and tools can take unintended or unsafe actions.

Identity Has To Mean Attribution Not Just Access

In practice, agents will keep authenticating through the mechanisms organisations already recognise, service accounts, workload identities, API credentials. But treating an agent as just another service account with extra metadata misses the point. Security teams need to identify the individual agent, understand the authority it’s been given, know who or what it’s acting on behalf of and trace its actions back to that authority.

That becomes non-negotiable once agents start spawning or delegating to other agents: every agent in a delegation chain needs to be visible, including previously unregistered ones, and every step of how permissions were passed down needs to be traceable. Delegation can’t be allowed to break attribution or accountability, if any link in that chain is invisible, both collapse together.

What Good Telemetry Actually Captures

Much of the underlying telemetry already exists across identity, application, API and infrastructure logs, it’s rarely captured with enough agent-specific context to be useful. Security teams need to know which agent acted, what task it was carrying out, what authority it was using, which tools or systems it called, and what happened as a result, joined into a coherent, risk-scored sequence rather than isolated log lines.

UEBA’s underlying methodology, establish normal, identify meaningful deviation, correlate activity, assess risk, still applies. What changes for agents is what gets baselined, not the discipline itself.

There’s No Safe Agent-Per-Analyst Ratio

It’s tempting to look for a rule of thumb, some ratio of agents to analysts beyond which manual review breaks down. There is no safe agent-per-analyst ratio and chasing it misses the point. What determines the breaking point is how often agents act, how autonomous they are, what systems they can touch, and the potential consequences if something goes wrong. The operating model also needs predefined intervention thresholds, when activity can be automatically constrained or stopped, when human approval is required, and who has authority to make that decision where business impact could be significant.

What’s already clear is that once agent activity reaches high volume at machine speed, manual review alone doesn’t scale. The tell-tale sign of drift is rarely a single event; it’s a pattern of scope creep, tool use outside the task, or activity that continues after the task should have ended, that can no longer be reconciled with the agent’s stated purpose.

Accountability Must Be Clear, Responsibility Is Shared

No single team should own agent risk end to end. The team deploying an agent stays accountable for its purpose and operation; security’s role is to assess risk before deployment, reviewing code and configuration where applicable, validating permissions and controls and making sure the right monitoring is in place and that assurance has to continue after go-live through ongoing monitoring, testing and audit.

The level of scrutiny should scale with the agent’s autonomy, access and potential business impact, not be applied uniformly regardless of risk.

What A CISO Should Have In Place Within 12 Months

Concretely know which agents are operating and who owns each one; understand what they’re allowed to do and what data and systems they can reach; and size their autonomy honestly. From there, apply proportionate controls, strong identity and least privilege, security testing before deployment where appropriate, continuous behavioural monitoring and assurance across behaviour, permissions and material changes clear approval and escalation points, and regular audit and revalidation as agents, permissions and integrations change.

The goal isn’t to treat every agent as high risk. It’s to make sure the organisation can see, govern and intervene where the business impact of getting it wrong would actually be significant. NCSC’s blog is a useful prompt to start that conversation now, while it’s still interim advice, not once formal guidance forces the issue.