AI Agent Security for CISOs: The Agents You Didn't Approve Are Still Your Problem
Watch: Humanbound CISO Introductory Video — "Know what can break, before it does." (80 seconds)
Key takeaways
- Every AI agent in an organization, approved or not, can typically read sensitive data and take real actions on its own. Shadow deployments carry the same access as sanctioned ones, without the same oversight.
- EU AI Act transparency obligations and AI Office enforcement powers took effect on August 2, 2026. DORA and NIS2 already govern the systems many agents touch. "We trust the model" is not an answer that holds up to a board or an auditor.
- Testing an agent once, before launch, tells you nothing about how it behaves six months and a dozen model or prompt updates later. Security posture needs to be tested the way it's attacked: continuously.
- A single, comparable metric, a security posture score, turns "we think it's fine" into evidence a board or auditor can actually evaluate.
The two agents in your environment
Most security conversations about AI start with the agents a company knowingly built and shipped: the customer support bot, the internal coding assistant, the workflow automation tied into the CRM. Those get a launch review, maybe a pen test, a line in the risk register.
The agents nobody signed off on don't get any of that. A team spins one up with a SaaS trial, a marketer wires an agent into a spreadsheet with edit access to shared drives, an engineer connects an assistant to internal APIs to save an afternoon. From a capability standpoint, there is no meaningful difference between the approved agent and the shadow one. Both can read sensitive data. Both can take real, consequential actions without a human in the loop for every step. Only one of them shows up when security asks what AI is running in the environment.
This is the starting frame of Humanbound's CISO introductory video, and it's worth sitting with rather than rushing past: the risk isn't "AI agents," in the abstract. It's the gap between the agents an organization knows about and the agents actually running with production access.
The question that actually matters
Given that gap, the practical question isn't whether an organization is using AI agents. Nearly all are, whether centrally tracked or not. The question the video poses is sharper: when one of those agents does something it shouldn't, does the organization find out before it happens, or after?
Before means a testing and monitoring program that surfaces failure modes ahead of an incident: an agent that can be talked into exfiltrating data it was never meant to touch, or one that takes an action outside its intended scope under the right adversarial pressure. After means an incident report, a post-mortem, and the uncomfortable realization that the exposure existed the entire time it just hadn't been tested for.
The cost of finding out after isn't only the incident itself. It's the conversation that follows it, with a board, a regulator, or a customer, about what was actually done to prevent it.
The compliance ground has already shifted
That conversation is no longer hypothetical, and the regulatory backdrop is less forgiving than it was even a year ago.
The EU AI Act's prohibited-practices provisions have applied since February 2025. General-purpose AI model obligations, including technical documentation and training-data transparency, have applied since August 2025. As of August 2, 2026, the Act's Article 50 transparency obligations apply, and the AI Office's supervision and enforcement powers over general-purpose AI models are operational. (Obligations for high-risk systems under Annex III have been pushed out to December 2027, and Annex I safety-critical systems to August 2028, so it isn't full enforcement across every category yet, but the enforcement machinery for the obligations already in force is now live.)
Alongside that, DORA has applied to EU financial entities' operational resilience, including the technology they rely on, since January 2025, and NIS2 extends cybersecurity risk-management obligations across a wide range of essential and important entities. None of these frameworks were written with "AI agent" as a defined term. That doesn't exempt agents: if an agent touches personal data, financial operations, or critical infrastructure, the systems and processes around it are already in scope.
Put together, this is the context in which "we trust the model" stops functioning as an answer. A board or an auditor asking what was done to secure an autonomous system that can read data and take action is not asking about intentions. They're asking for evidence.
Why testing once a year doesn't produce that evidence
Traditional application security has a cadence: build, test, ship, retest on a schedule, maybe annually or at major releases. AI agents don't hold still the way traditional software does. The underlying model gets updated. The system prompt gets tweaked. A new tool gets connected. Each of those changes the agent's behavior in ways that a test run six months ago can't speak to.
Humanbound's approach, described in the video as testing an agent "the way an attacker would, continuously, not once a year," treats adversarial testing as an ongoing process rather than a launch gate. The mechanism matters less here than the principle: a finding from adversarial testing shouldn't sit in a report. It should feed directly back into how the agent is defended in production, so that what was learned in testing becomes active protection rather than a to-do item that ages out of relevance by the next quarterly review. Humanbound's own published analysis of publicly reported agent-security incidents makes the related point directly: the common failure pattern in these cases wasn't a missing piece of infrastructure, it was that the agent's behavior under adversarial conditions had never been tested at all (source).
The scale of the gap this leaves is not small. By Humanbound's own accounting, only 14.4% of AI agents in production deploy with full security approval, roughly 80% of organizations report agents exhibiting risky behavior, and the average enterprise is running around 1,200 unofficial AI applications outside formal governance (source). Those numbers describe the shadow-agent problem from the opening section of this piece in concrete terms.
One number a board can actually use
The output a security or risk leader needs from all of this isn't a stack of findings. It's a comparable answer to "where do we stand," and a way to track whether that answer is improving.
That's the role of a security posture score: a single 0 to 100 metric (with a corresponding letter grade, A through F) that combines two things: the severity of an agent's active security findings, and how much of its realistic attack surface has actually been tested and passed. An agent that scores well hasn't just avoided known issues; it has been tested against a broad set of adversarial scenarios and held up. Tracked over time, the score shows whether an organization's AI agent estate is getting more resilient or drifting the other way, which is the trend line a board actually wants to see, not a single point-in-time assessment.
This is the "proof, not promises" moment the video builds toward: not a claim that agents are secure, but a number, and a trend, that can be produced on request.
Frequently asked questions
What is a "shadow AI agent"?
A shadow AI agent is an AI agent running in an organization's environment, with real access to data or systems, that wasn't reviewed or approved through the organization's formal AI governance process. It typically has the same technical capabilities as an approved agent, reading sensitive data, calling internal tools, taking autonomous actions, without the same visibility or oversight.
Does the EU AI Act apply to AI agents already in production?
It depends on what the agent does and what data or systems it touches, not on whether "AI agent" appears anywhere in the regulation. Prohibited-practice restrictions have applied since February 2025, and general-purpose AI model obligations since August 2025. As of August 2, 2026, Article 50 transparency obligations apply and AI Office enforcement powers are active. High-risk system obligations under Annex III are not mandatory until December 2027. Separately, frameworks like DORA and NIS2 already impose operational-resilience and cybersecurity obligations on many of the systems agents are connected to, regardless of AI-specific rules.
What's the difference between testing an AI agent once before launch and testing it continuously?
A pre-launch test captures how an agent behaves against a specific model version, prompt, and tool configuration at a single point in time. Continuous testing accounts for the fact that agents change, through model updates, prompt edits, and new tool integrations, and re-tests against adversarial scenarios on an ongoing basis so that new behavior gets evaluated before it becomes an incident rather than after.
What is an AI agent security posture score?
A security posture score is a single metric, typically 0 to 100 with a letter grade, that summarizes an agent's security state by combining the severity of its current findings with how thoroughly its attack surface has actually been tested. It's designed to give security leaders and boards one comparable number, tracked over time, instead of a raw list of findings.
Is a posture score the same as a compliance certification?
No. A posture score is an internal, continuously updated measure of how an agent has performed under adversarial testing. It's evidence an organization can point to when asked what it has done to secure an agent, but it isn't a substitute for whatever formal compliance certifications or audits a specific regulation requires.
The point of the 80 seconds
None of this is meant to be dramatic. The video this article supports is deliberately undramatic by design: no hacker-movie visuals, no "AI is scary" framing without a mechanism attached. The point isn't that AI agents are uniquely dangerous. It's that they already have real access and real autonomy, that regulators and boards are starting to ask what's been done about it, and that "we trust the model" isn't going to be the answer that satisfies either of them.
Know what can break, before it does.
Sources
About the author
Co-founder of Humanbound, an AI security testing platform helping enterprises secure their AI agents. Based in Athens, Greece.