What Is an AI Agent? (And Why "Agent" Means Three Different Things)

The word agent now describes everything from a chatbot to a system that authenticates to production infrastructure on its own. That ambiguity is causing real problems, especially for security teams trying to figure out what to govern, and how.

The short answer: "AI agent" doesn't mean one thing. It means three different things, with three very different security implications.

The Simplest Definition

An AI agent is a software system that uses a large language model to take actions on behalf of a user, with some degree of autonomy. It receives a goal, decides what to do next, calls tools or APIs to do it, and uses the result to inform its next decision.

In practice, that label gets applied to systems ranging from "answers questions in a chat window" to "deploys infrastructure across your AWS accounts." Treating them as one category is where security planning breaks down.

The Three Things People Call "Agents"

1. Chatbots and Assistants

LLM-powered interfaces that respond to user input. They generate text, summarize documents, and draft emails. They don't take actions outside the conversation. Ask one to "send this email" and it shows you a draft. It doesn't actually send anything.

The main risks are data exposure (what's in the prompt) and content (what the model returns). The model is the surface area.

2. Copilots

A copilot adds capabilities to an existing application: code completion in an IDE, draft suggestions in a document editor, query generation in a database tool. The user is still in the loop for every action. The copilot proposes; the human approves.

Risk increases here because the copilot has more context (your code, your documents, your data), and the line between suggestion and action gets thinner. But a human still pulls the trigger.

3. Autonomous Agents

This is the category that's structurally new. An autonomous agent is given a goal, decides on its own how to achieve it, calls tools and APIs without per-step human approval, and operates with its own credentials.

Examples: a Cursor or Claude Code agent running on a developer's laptop with MCP servers connected to GitHub and Slack. A LangChain or CrewAI workflow running on Lambda that authenticates to AWS and Salesforce. A Bedrock or Vertex agent deployed in production with access to customer data.

This third category is where most enterprise security stacks fall short. Chatbots and copilots fit reasonably well into existing controls: model governance for the first, application security for the second. Autonomous agents don't fit either, because the agent itself is acting on infrastructure with credentials your team probably didn't know it had.

Why the Distinction Matters for Security

The three categories carry three different threat models.

For chatbots, the controls are output filtering, prompt logging, and content policy.

For copilots, the controls are scoping the assistant's access and keeping a human in the loop for sensitive actions.

For autonomous agents, neither set of controls applies. Output filtering doesn't help when the agent is calling APIs autonomously. Keeping a human in the loop defeats the purpose. The whole point is that the human isn't in the loop.

For autonomous agents, the security model shifts to the identity layer. Which non-human identities is the agent using? What can those identities reach? Who deployed the agent, and is that owner still around? When the agent does something unexpected, can you detect it before damage is done?

What to Do With the Definition

If you're trying to figure out which "agents" your organization needs to govern, start with the third category. Chatbots and copilots are real, but the controls for them already exist in most security stacks. Autonomous agents are the category where the security model has to be rebuilt.

For each autonomous agent in your environment, four questions are worth answering:

• Who deployed it?
• What credentials does it hold?
• What can those credentials access?
• What is the agent doing right now?

If those answers don't exist for the agents already running in your environment, that's the gap to close first.

The next post in this series goes deeper on what makes autonomous agents structurally different from anything security teams have governed before: the four properties that combine into a genuinely new category of risk.