Around GBI Impact New York, CISO Platform brought together a small group of senior security leaders for a private breakfast hosted by FireCompass at Conrad Downtown, New York. The format was intentionally simple: no slides, no pitches, no stage. Just a focused peer conversation over breakfast on one of the most urgent questions facing security leaders today : As AI agents start doing real security work, how do we run them safely?
The discussion centered on two connected themes:
- AI Agents in Offensive Security
How autonomous and semi-autonomous agents may change security testing, validation, attack simulation and remediation workflows. - Governance of AI Agents
How CISOs can create the right guardrails before agents are given access, authority and execution power inside enterprise environments.
Date 25 June, 8 AM, Conrad Downtown
AI Agents Are Doing Security Work. Who Sets the Guardrails?
Security teams are already handing real work to AI agents: triaging alerts, running reconnaissance, drafting detections, and in some shops taking actions in live environments. The open question for senior leaders is no longer whether agents can do the work. It is how to let them do it safely, with accountability that holds up to an auditor and a board.
That was the thread running through a recent closed-door breakfast for security leaders in New York, convened by CISO Platform and co-hosted with FireCompass. No slides. No product pitches. Just practitioners comparing notes on a problem most of them are hitting at the same time.
The question that kept coming back
As agents move from suggesting to acting, the governance model built for human analysts and for static tooling starts to crack. An agent that reads a ticket carries one risk profile. An agent that can change a firewall rule, disable an account, or push a config to production carries another. The room kept returning to the same line: the moment an agent can take an action, you are no longer governing a tool. You are governing a worker that never sleeps, never asks permission twice, and can repeat a mistake a thousand times before anyone notices.
What changes when the agent acts on its own
A few themes surfaced repeatedly, and they map cleanly to the frameworks security leaders are already reaching for.
The first is scope. Most teams can describe what a human analyst is allowed to touch. Far fewer can describe the blast radius of an agent with a service account and an API key. The NIST AI Risk Management Framework is useful here as a way to make "what could this go wrong, and how badly" an explicit, documented decision rather than an assumption.
The second is identity. An agent acting in your environment is a privileged actor. The OWASP Top 10 for LLM Applications and its more recent work on agentic risks point at the same gap: prompt injection, excessive agency, and over-broad permissions are not edge cases once an agent can call tools on its own.
The third is evidence. If a human admin disables an account, there is a log, an owner, and a story you can tell later. Several leaders made the point that agent actions need to meet that same bar, or the first serious incident becomes unexplainable. MITRE's ATLAS knowledge base is one starting point for thinking through how these systems get attacked and abused, not just how they help.
Why a closed room beats a conference panel
None of the above is secret knowledge. What is hard to find is a candid read on what is actually working, from peers who carry the same accountability you do. On a conference floor, the honest version of "we tried this and it broke" rarely gets said out loud. In a small room with no vendors selling, it does. That is the entire reason these gatherings exist, and it is why the most useful takeaways tend to be the failures, not the wins.
What to do on Monday, even if you weren't in the room
The conversation pointed to a short, practical starting list any security leader can act on now:
- Inventory where agents already have access. In most organizations this has grown faster than anyone has tracked.
- Treat every agent identity as a privileged identity, with the same scrutiny, rotation, and least-privilege you apply to human admins.
- Define the blast radius before you grant the access. Decide which actions an agent may take autonomously and which require a human approval gate.
- Log agent actions to the same standard you would demand of a person doing the same task. If you cannot reconstruct what an agent did and why, you cannot defend it.
- Decide deliberately where a human stays in the loop, and write it down. The default of "wherever it felt risky at the time" does not survive an incident review.
The takeaway
AI agents in security operations are not a future problem to plan for. They are a present-tense governance gap that most teams are filling informally, one access grant at a time. The leaders moving fastest are not the ones with the most automation. They are the ones who decided, on purpose, what their agents are allowed to break.
If conversations like this are useful to you, CISO Platform is a free, vendor-neutral community where security leaders share exactly this kind of first-hand experience. Join the community (free).
Comments