Skip to content
aizome
Blue image of people writing notes at a table.

AI Agent Security Isn’t Too Complex to Start. You’re Just Missing the Map.

Chen Pipek, CPO & Co-founder aizomeChen Pipek· CPO & Co-Founder, aizome8 min read

I do a lot of demos. And lately, I keep having the same conversation.

Not because our product is hard to understand. Because the category is drowning in noise - and the CISOs I meet are genuinely overwhelmed. They have attended the sessions. They have read the analyst reports. They have sat through a dozen vendor pitches. And they still walk into the room unsure of what they need, what to prioritize, and where to start.

That is not a failure of intelligence or effort. It is a failure of clarity in a market that has produced more acronyms than answers. ARISE. NHI. Agentic IAM. AAEL. Intent governance. MCP security. Guardian agents. Every vendor is emphasizing a different capability. Every analyst is naming a new category. And the CISO is left holding thirty vendor decks with no coherent map.

This blog is the map.

Not a product pitch. A framework for thinking about AI agent security in plain language, what actually matters, in what order, and how to evaluate whether a vendor is solving the real problem or selling a label.

Why It Feels Impossible to Start

AI agent security feels complex because the market isn’t always talking about it in the right way.

Most of what you’re hearing is a solution in search of a prioritization. Vendors are leading with their strongest capability - intent analysis, behavioral monitoring, MCP governance, zero-trust for agents - without giving you a framework for understanding where that capability sits in the sequence of what you actually need to build.

The result is that every vendor sounds equally important and equally urgent, and the natural response is paralysis. You cannot do everything at once. You need to know what comes first.

Here is the honest answer: AI agent security is not one problem. It is a sequence of three problems. And the sequence matters more than the solutions, because solving them out of order produces governance infrastructure that looks complete and fails in production.

The Map: Three Questions That Cut Through Everything

Before evaluating any vendor, capability, or framework, ask yourself these three questions about your current environment:

Question 1: Do you know what AI agents are actually running in your environment?

Not what was approved. Not what IT provisioned. What is actually running - including the agents built by employees on a Tuesday afternoon, the agents enabled by SaaS vendor updates your team didn’t notice, and the agents spun up by engineering teams moving fast.

If you cannot answer this question with confidence, you have a discovery problem. And a discovery problem means every other governance decision you make is built on an incomplete foundation. You are governing the agents you know about. The ones you don’t know about are your actual risk.

Question 2: Do you know what each agent is authorized to do - and who owns it?

Not what the agent could theoretically access. What it was specifically built to do, what its authorized scope is, and which human being is accountable for its behavior.

If you cannot answer this question, you have an identity and accountability problem. Agents without documented owners are liabilities for which no one is responsible. Agents without defined scope are permission sets waiting to be abused.

Question 3: Do you know what each agent is actually doing right now?

Not what it did last quarter. Not what the audit log shows from last week. What it is doing at this moment - whether its behavior is consistent with what it was built to do, whether it has drifted from its defined purpose, and whether any of its actions in the last session fell outside its authorized boundaries.

If you cannot answer this question, you have a runtime governance problem. And runtime governance is the layer that makes the first two answers meaningful - because an agent with a known identity and a defined scope can still cause significant harm if nobody is watching what it does with that identity and scope in real time.

These three questions define the sequence. Discovery first. Identity and accountability second. Runtime governance third. In that order. Every time.

What to Prioritize - And Why the Sequence Matters

Start with discovery.

You cannot govern what you cannot see. This sounds obvious. It is consistently underestimated. Most enterprises begin their AI agent governance programs with policy documents and approved vendor lists - and then discover, usually during their first real inventory, that the number of agents actually operating in their environment is significantly higher than anyone expected.

Discovery has to come before everything else because it defines the scope of everything else. A governance program built on an incomplete inventory has unknown blind spots. Those blind spots are where the risk accumulates.

Real discovery does not depend on agents announcing themselves. It finds agents through the infrastructure you already have - integrating with your EDR, your MDM, your identity providers, your SaaS platforms - and surfaces everything operating in your environment, registered or not.

Then establish identity and ownership.

Every agent needs three things: a verified identity, a documented human owner, and a structured definition of what it was built to do. Not a natural language description. A precise, machine-readable definition of the agent’s authorized systems, data types, and actions - the organizational intent that becomes the baseline for every governance decision that follows.

This is also where the question of accountability gets resolved. When something goes wrong with an agent, there needs to be a specific person - not a committee, not a team - who is responsible for that agent’s behavior. Ownership mapping is not bureaucracy. It is the prerequisite for accountability.

Then add runtime governance.

With discovery complete and identity established, runtime governance becomes meaningful. Without the first two layers, it produces noise - alerts about agents you cannot identify, deviations from baselines that don’t exist, accountability gaps with no owner to close them.

Runtime governance is the layer that continuously evaluates whether an agent’s actual behavior is consistent with its organizational intent - before actions execute, not after consequences arrive. It is what makes governance continuous rather than periodic and closes the gap between what an agent is authorized to do and what it actually does in production.

What to Ignore (For Now)

One of the most valuable things a clear map gives you is permission to deprioritize.

Advanced threat detection before you have behavioral baselines. You cannot detect deviation from a baseline that does not exist. Deploying sophisticated anomaly detection before you have established what normal looks like for each agent produces false positives that train your team to ignore alerts - the worst possible outcome.

Multi-agent chain governance before you have single-agent governance. Chain accountability is genuinely important - and it is the right problem to solve after you can answer the three questions above for individual agents. Solving chain governance first, without the identity and intent foundation, produces audit trails that record what happened without being able to explain whether it should have.

Compliance reporting before you have operational controls. A board-ready dashboard built on incomplete discovery and no runtime governance is a reporting capability, not a governance capability. Get the controls right first. The reporting follows naturally from controls that work.

Shopping for the right vendor? Here are the five questions that expose whether a vendor is solving the real problem

When you sit across from a vendor - any vendor, including us at aizome - these are the questions that tell you whether they are solving your actual problem or selling you a capability in search of a sequence.

  1. “Can you find agents in my environment that were never formally registered?” If the answer depends on agents self-registering or IT submitting a list, you are looking at a governance tool, not a discovery tool. Real discovery finds what exists, not what was reported.
  2. “When an agent takes an action, can you tell me whether that action was consistent with what the agent was built to do - before it executes?” If the answer is “we log it and alert on anomalies,” you are looking at monitoring, not governance. Real runtime governance evaluates intent before execution, not after consequences.
  3. “If I need to stop an agent in the next 60 seconds, what does that look like?” If the answer requires a manual process, a chain of escalations, or depends on the agent itself responding to a shutdown command, you do not have operational containment. You have a policy that assumes the agent cooperates with being stopped
  4. “Who is accountable for this agent’s behavior in your model?” If the answer is a team, a policy, or a governance committee - ask again. Real accountability requires a named human being. The moment accountability diffuses across a team, it effectively disappears
  5. “What is out of scope for your platform - and what should I use instead?” A vendor that claims to cover everything has not thought carefully enough about the problem’s scope. The honest answer names specific capabilities the vendor does not provide and points you toward the right complementary tools. Trust the vendor who tells you what they do not do.

It Is Not That Complex (and it doesn’t have to be). Start Here.

AI agent security is not one problem. It is a sequence of three. Discovery, then identity and accountability, then runtime governance. In that order. Every capability the market is selling you fits somewhere in that sequence - and most of it is genuinely useful once you know where it belongs.

The CISOs who are moving confidently on AI agent security are not the ones who solved everything at once. They are the ones who answered the three questions, started with discovery, and built from there.

You do not need thirty vendor decks. You need a map and a starting point.

The map is the three questions. The starting point is the first one you cannot answer.

Chen Pipek is CPO and Co-Founder of aizome, an Enterprise AI Agent Identity Fabric Platform. He previously co-founded and led AxoniusX within Axonius and has held product and security leadership positions for over 20 years.

Chen Pipek, CPO & Co-founder aizome

Chen Pipek

CPO & Co-Founder, aizome

Related content

The latest news, technologies, and resources from our team.

  • Your Board Wants an Agentic AI Governance and Compliance Score. Here It Is.

    Most enterprises run their first EU AI Act compliance assessment and land at 21%. Not because they ignored the regulation - because the controls it requires live at the infrastructure layer, and no tool in their existing stack was built to enforce or score them. AI Compliance Posture changes that: a live compliance score across OWASP, MITRE ATLAS, ARMCF, NIST AI RMF, and the EU AI Act, with the gaps identified and the remediation actions built directly into the platform. The score your board is about to ask for now exists.

    aizome

  • Your AI Security Vendor Cannot Answer These Questions - And That Is the Problem

    Something is shifting in how enterprises evaluate AI agent security vendors. Twelve months ago, the conversations were broad. What do you cover? What does the dashboard look like? Can you show me a demo? Now the questions are specific. And the vendors that cannot answer them are getting cut from the shortlist faster than anyone expected.

    aizome

  • Five Questions Every CIO Should Be Able to Answer About Their AI Agents

    Your Finance team built an AI agent last Tuesday. It is connected to SAP. HR has one connected to Workday. Sales built three connected to Salesforce. None of them went through IT. None of them have a governed identity. And nobody is watching what they are actually doing. This is a CIO problem. Because when the board asks - which AI agents are connected to our critical systems, what are they costing us, and who is accountable - the answer has to come from you. Most CIOs cannot answer those questions today. Not because they are not paying attention. Because the infrastructure to answer them does not exist in their current stack.

    aizome

  • The Enterprise AI Agent Revolution Is Here - My CYBER.SEC.CON Reflection

    Someone walked up to our booth and asked: “So what do you do - is this like a guardrails thing?” It is a reasonable question. Most of what people have heard about AI security has been about guardrails - content filters, output moderation, prompt sanitization. The assumption baked into that question is that the risk lives at the language layer. That assumption is no longer the right one. And the gap between where most people think the risk is and where it actually is - that is where the incidents are happening.

    Amir Ofek

    Amir Ofek

  • The Problem Has Moved From Prompt Hygiene to Access Architecture

    The conversation about AI agent security has been dominated by the wrong question. For the last two years, most of the energy in this space has gone into making AI agents say the right things. Guardrails. Output filters. Prompt sanitization. The implicit assumption is that the risk lives at the language layer. That assumption is now definitively wrong. The problem has moved from prompt hygiene to access architecture. The risk is not what agents say. It is what they do - with authorized access, through legitimate tool calls, in ways that no output filter was designed to evaluate.

    Chen Pipek, CPO & Co-founder aizome

    Chen Pipek

  • When a Support Ticket Emails Your Customer Database

    Support teams do something no other department does on purpose. They let strangers write directly into their systems. Customers paste logs, forward email threads, attach files, and describe problems in whatever words they have. An AI agent can turn that pile into a clean morning queue summary. It can also read it as instructions. We built a complete indirect prompt-injection chain using Salesforce and Claude Desktop. An outsider filed a plausible billing ticket through a public support form. Later, an employee asked Claude to summarize the day’s queue. Claude read the ticket, followed a short routing block buried inside it, exported 25 Accounts, 25 Contacts, and 25 Cases, and mailed the package to an external address.

    aizome Research Labs

Subscribe to the Aizome newsletter

Occasional, substance-first notes on making enterprise AI agents accountable. No spam; unsubscribe anytime.

We use your email only to send you our newsletter. See our privacy policy for how we handle your data. You can unsubscribe at any time.