What Is Agentic AI Security

Most AI systems people met first were chatbots. You asked a question, the system answered, and nothing happened in the wider business. An agent is different. It plans, it calls tools, it reads and writes data, and it carries out tasks across the systems it can reach. The output is no longer text on a screen. It is an action.

That shift is why agentic AI security exists as its own discipline. When software can take actions, the questions change from what did it say to what was it allowed to do, what did it actually do, and who would have known if it went wrong.

Why it differs from normal application security

Classic application security rests on assumptions that agents quietly break. Three assumptions matter most.

• Agents read untrusted content. An agent routinely ingests text from emails, documents, web pages, and tickets. Any of that content can carry instructions aimed at the agent rather than at a person, and the agent may follow them.
• Agents choose which actions to take. Traditional software runs a fixed path a developer wrote and reviewed. An agent decides at runtime which tool to call and with what inputs, so the behavior you need to govern is not fully knowable in advance.
• Agents keep their own memory. An agent carries context and state across steps and sessions. That memory can be read, poisoned, or leaked, and it becomes a target in its own right.

Because of these three properties, the controls that protected request and response applications do not, on their own, cover an agent. The risk has moved into the reasoning layer, the place where the agent decides what to do next, and that layer is one traditional controls were never built to inspect.

How agentic systems get attacked

Attack paths against agents target decisions and access, not just code. The common ones are worth knowing by name, because they show up in board conversations and in vendor pitches alike.

• Prompt injection. Untrusted content the agent reads carries hidden instructions, and the agent treats them as if they came from you. This is the headline attack against systems that act on what they read.
• Tool and connector misuse. An agent is given access to tools and data sources to do its job. An attacker steers it into using that access in ways you never intended, often without breaking any individual permission.
• Agent memory leakage. Sensitive context stored in the agent's memory is extracted, or memory from one user or task bleeds into another.
• Multi-agent cascades. Where agents call other agents, a single bad instruction or output can propagate across the chain, and the failure compounds faster than a human can intervene.

Two reference frameworks describe this territory in public, vendor-neutral terms. The OWASP Agentic Security Initiative (ASI) catalogs threats specific to agents, including the patterns above. MITRE ATLAS maps adversary tactics and techniques against AI systems, in the spirit of the attack and defense matrices security teams already use. Both are useful for naming risk consistently across your business.

Posture is not protection

It is tempting to treat this as a tooling purchase. Discovering and scanning your AI shows what you have and where it is weak, which is genuinely useful and the right place to start. On its own, it stops nothing at runtime. Visibility comes first, but visibility is not a control.

It is also worth saying plainly: some of the hardest gaps here are architecture, not something a product fixes. How an agent's memory is isolated, how its access is scoped, and how untrusted content is separated from trusted instructions are design decisions. No purchase closes them for you.

Why this is a board responsibility

Oversight of material technology and model risk sits with the board. Agentic AI fits that category cleanly, because an agent can move money, change records, and reach customers with limited human review. The exposure is operational and fiduciary at the same time.

Regulators and standards bodies are converging on the same expectation: that AI is inventoried, governed, and evidenced. Frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001 set out how organizations are expected to manage AI risk and demonstrate that they are doing it. The board does not need to read the standards. The board does need to be able to ask whether the organization knows where its agents are, what they can do, and how that is controlled.

How to start

Start by knowing your posture before you decide what to buy or build. The free AI security assessment maps your posture across seven control domains and produces a board-ready gap assessment and roadmap. It tells you what is wrong. It does not hand you the implementation, because closing some of these gaps is design work, not a checklist.

From there, the next questions are honest ones. Which gaps are tooling, which are architecture, and which have no product that solves them today. Naming that clearly is the difference between a roadmap you can defend to a board and a shelf of dashboards that scan but do not protect.