TL;DR
- What changes with agents: a chatbot can give a wrong answer; an agent can take a wrong action. Security shifts from filtering text to controlling permissions and approvals.
- Top risks: goal hijack through injected instructions, tool misuse, privilege abuse, poisoned memory and cascading failures, as catalogued in the OWASP Top 10 for Agentic Applications.
- Five control layers: input, identity and permissions, tools and sandbox, output checks, human approval and logging.
- What needs manual approval: sending data outside the company, deleting records and spending money, at least until the agent has a track record.
- Choosing tooling: match platform categories to gaps, and judge products on discovery, per-tool permissions, runtime blocking, audit logs, integrations and data location.
What is AI agent security?
AI agent security is the set of controls that keep an autonomous AI system from being tricked, over-privileged or allowed to cause harm while it reads data and acts on other systems. It covers what the agent can access, which identity it uses, which actions it may take without a person, and how every step is recorded.
The difference from chatbot security fits in three lines. A chatbot can produce a wrong or unsafe answer. An agent can take a wrong or unsafe action: send a file, change a record, approve a payment. So the focus moves from content filters to permissions, approvals and audit trails.
The stakes are already measurable. IBM's Cost of a Data Breach Report 2026 puts the global average cost of a breach at USD 4.99 million for the organizations studied. Agents that hold credentials and act on several systems widen the paths to that kind of incident. CodeGeeks Solutions treats access rules, approvals and logging as part of the agent's design from the first sprint, because adding them after launch usually means rebuilding the integrations.
AI agent security risks
The OWASP Top 10 for Agentic Applications 2026, released in December 2025, is the most widely used reference for agent-specific threats. The table maps eight of its ten categories to plain examples and a first control.
Table 1. Agent risks mapped to the OWASP Top 10 for Agentic Applications
| Risk (OWASP ID) | Plain example | First control |
|---|---|---|
| ASI01 Agent Goal Hijack | A supplier email contains hidden text telling the agent to forward invoices to a new address | Treat all retrieved content as untrusted; require approval for changes to payment details |
| ASI02 Tool Misuse and Exploitation | An agent allowed to query a database runs an export of the full customer table | Narrow tool scopes and rate limits per tool |
| ASI03 Identity and Privilege Abuse | The agent runs with an admin service account, so any user can reach admin data through it | Separate agent identity; act with the requesting user's rights |
| ASI04 Agentic Supply Chain Vulnerabilities | A third-party plugin or tool server is updated with malicious instructions | Allow-list tools and pin versions; review before updates |
| ASI05 Unexpected Code Execution | Generated code runs on a server with network access | Sandbox code execution; block outbound network by default |
| ASI06 Memory and Context Poisoning | A false "policy" stored in long-term memory changes later decisions | Validate what enters memory; expire and audit stored items |
| ASI07 Insecure Inter-Agent Communication | A fake message, apparently from the billing agent, approves a refund | Authenticate and sign messages between agents |
| ASI08 Cascading Failures | One agent's wrong output is accepted by three downstream agents | Validation between steps; circuit breakers and step limits |
The other two categories, human-agent trust exploitation (ASI09) and rogue agents (ASI10), are covered by the approval and monitoring controls later in this guide. For model-level risks such as prompt injection and excessive agency, the OWASP Top 10 for LLM Applications 2025 remains the companion reference.
AI agent security considerations before deployment
Before an agent goes live, five questions need short, written answers:
- 1. What can the agent touch? List every system, data set and tool, with read or write rights for each.
- 2. Whose identity does it use? Its own service identity, the requesting user's rights, or both. Never a shared admin account.
- 3. What data enters its memory and logs? Personal, financial or confidential data needs a retention rule and access limits.
- 4. Which actions need human approval? Decide before launch, not after the first incident.
- 5. Who owns it? One named person who answers for the agent's behavior and reviews its logs.
If any answer is "not sure," the agent is not ready for production data.
AI agent security measures: guardrails and controls
In AI agent security, guardrails (filters on what goes into and comes out of the model) are useful but not enough on their own. Determined attackers regularly find phrasing that slips past them. What limits damage when a guardrail fails is the set of permissions and approvals around the agent. Figure 1 shows five layers a request should pass before anything changes in a real system.
Figure 1. Five control layers. Guardrails cover layers 1 and 4; layers 2, 3 and 5 limit the impact when a guardrail is bypassed.
The permission matrix below turns layers 2 and 5 into a rule set. It is an editorial starting point, not a standard; each organization should adjust it to its risk appetite and regulations.
Table 2. Permission matrix (starting point)
| Action type | Example | Rule |
|---|---|---|
| Read non-sensitive data | Product catalog, public docs, internal FAQ | Allow |
| Read sensitive data | Customer records, contracts, HR files | Allow with logging, within the requesting user's rights |
| Write internal data | Update a ticket status, add a CRM note | Allow with logging; bulk changes need approval |
| Send externally | Email a customer, post to a partner system | Human approval |
| Delete or spend money | Delete records, issue refunds, place orders | Human approval |
| Change permissions or configuration | Grant access, change agent settings | Human only; agent may draft the request |
When CodeGeeks Solutions designs AI assistants, approval steps and "must-not-do" rules are written into the workflow specification alongside the features, so the client's team can review the limits before any code is deployed.
AI agent data security
Protecting data around an agent starts with giving it less. Data minimization means the agent receives only the fields a step needs, not the whole record. Access should follow the requesting user's rights, so an agent cannot show a junior employee a document their own account could not open.
Memory and logs need the same care as databases. Conversation history, stored preferences and traces often contain personal data; they need retention limits, encryption and restricted access. Retrieval should draw only from approved, versioned sources, since a single planted document can poison answers for every user. The CodeGeeks article on agentic context engineering explains how context is assembled and why each source deserves a trust level.
AI agent security platform: how to choose
Tooling for AI agent security is changing fast, and most published roundups are written by vendors that rank their own product first. Thinking in categories is more useful than chasing a "best" list.
Table 3. Platform categories
| Category | What it does | When it is needed |
|---|---|---|
| Runtime protection | Inspects prompts, tool calls and outputs in real time; blocks risky actions | Agents act on production systems or handle untrusted input |
| Identity and access | Gives agents their own identities, scoped and short-lived credentials | More than one agent, or agents acting for many users |
| Posture and discovery | Finds agents, tools and connections across the company; flags misconfiguration | Teams build agents independently and nobody has the full list |
| Observability and logging | Traces every step and keeps an audit trail | Always; required for incident response and audits |
Six criteria help compare products within a category: agent discovery (can it find agents nobody registered?), per-tool permissions, runtime blocking rather than alert-only, audit logs that security teams can export, integrations with the existing identity provider and SIEM, and data location for prompts and logs. A short pilot against one real agent shows more than any datasheet.
What is each of your agents allowed to do today?
CodeGeeks Solutions can review a current or planned agent and map its tools, identities and data access against the permission matrix above, with a list of gaps to close before launch. Ask the AI transformation team for an agent permission review.
Governance controls: who owns what
Technical controls work only if someone owns them. AI agent governance can start with five steps:
- 1. Inventory agents. Record every agent in use, including pilots, with its tools and data access.
- 2. Name an owner for each agent, accountable for its behavior and its review cadence.
- 3. Set least privilege and document the permission matrix per agent.
- 4. Add approval and logging for every action marked as risky.
- 5. Review after incidents and at a fixed interval, and update limits based on what the logs show.
The NIST AI Risk Management Framework gives these steps a structure through its Govern, Map, Measure and Manage functions. US policy interest is rising too: in January 2026, NIST's Center for AI Standards and Innovation published a request for information on security considerations for AI agents. Governance also has a business side. Gartner expects over 40% of agentic AI projects to be canceled by the end of 2027 and lists inadequate risk controls among the reasons.
What recent incidents show
Most AI agent security news in 2026 follows the same plot: content the agent reads carries instructions it should ignore. In April 2026, Noma Security disclosed "GrafanaGhost," a chain of flaws in which hidden instructions in log data could lead Grafana's AI assistant to send internal data to an external server, according to CyberScoop; Grafana issued a fix. A week later, OWASP's Q1 2026 Exploit Round-up named misconfigured permissions and excessive autonomy as recurring enablers. The lesson: assume injection will happen and limit what a hijacked agent can do.
How CodeGeeks Solutions builds controls into AI workflows
CodeGeeks publishes no agent-security test results or certifications, so this section describes design practice only.
Assistants with clear limits. On its AI chatbot development work, CodeGeeks designs assistants that answer from approved sources, follow explicit "must-not-do" rules, fall back safely when unsure and hand the conversation to a person when needed. Access is controlled through enterprise identity providers such as Okta and Azure AD.
Access scoped by role. In the Inspection Management Platform, field technicians, administrators and clients each see and do only what their role allows. The same principle applies when an AI agent works inside such a system: it inherits role limits rather than bypassing them.
LLMs on large data sets. The Lead and Data Intelligence System applies LLM steps to a data set of more than 184 million records. At that scale, deciding which data a model may read in each step is a design task in its own right.
For regulated teams, CodeGeeks also offers free self-assessment tools on its site, including a FHIR API Security Checklist and a DORA Readiness Assessment; these cover API and operational resilience readiness, not AI agents specifically.
“Payments, deletions and anything that leaves the company wait for a person, at least until the logs show the agent handles that action reliably. We would rather design an approval step on day one than explain an irreversible action afterwards. Guardrails catch most problems; permissions decide how big the rest can get.”
— CodeGeeks Solutions AI engineering team
Put your first agents to work inside clear limits
CodeGeeks Solutions is an AI-native product engineering partner that helps organizations automate operations, modernize legacy systems and build AI-enabled products on secure, dependable data foundations. For teams planning their first production agents, the team designs assistants and automations with access rules, approvals and logging built in. Explore AI automation services and scope one agent that can go live with guardrails your security team accepts.
FAQ
What is AI agent security?
AI agent security is the practice of protecting AI systems that can take actions, not only produce text.
It covers four questions: what the agent can access, which identity it uses, which actions it may take without a person, and how its activity is recorded. Typical controls include separate agent identities, least-privilege permissions for every tool, sandboxed code execution, validation of model output before it reaches another system, human approval for risky actions, and complete audit logs. The field builds on application security and LLM security but adds risks that only appear when a model can act.
Examples are an attacker hiding instructions in an email the agent reads, an agent misusing a legitimate tool, or one agent passing a wrong result to several others. The OWASP Top 10 for Agentic Applications, released in December 2025, catalogs these threats and is the most common reference point for security reviews. For a business, the goal is simple: if the agent is manipulated, the damage it can do stays small and visible.
What are the biggest AI agent security risks?
The biggest risks are agent goal hijack, tool misuse, and identity and privilege abuse. Goal hijack happens when content the agent reads, such as an email, web page or document, contains instructions that redirect it.
Tool misuse is an agent using a legitimate tool in a harmful way, for example exporting a whole table when it only needed one row. Privilege abuse occurs when an agent runs with broad service credentials, so anyone who can talk to it effectively borrows those rights. Close behind are supply chain risks in third-party tools and plugins, unexpected code execution, poisoned memory that changes later decisions, insecure messages between agents, and cascading failures where one error spreads through a chain.
All of these appear in the OWASP Top 10 for Agentic Applications 2026, which assigns each an ID from ASI01 to ASI10. The common thread is that prevention alone is not enough. Teams also need limits on what a compromised agent can reach and logs that show what it did.
How is AI agent security different from chatbot or LLM security?
The main difference is that agents act, while chatbots only answer. LLM security focuses on the model's input and output: blocking prompt injection, preventing harmful or confidential text, and reducing hallucinations.
Those controls still matter for agents, but they are not sufficient. An agent holds credentials, calls APIs, writes to databases and may coordinate with other agents, so a successful manipulation can change records, move money or send data outside the company. That shifts the center of gravity to classic access-control questions applied to a new kind of actor. Which identity does the agent use? What is the smallest set of permissions it needs?
Which actions require a person to approve? How is every step logged for investigation? Agents also introduce risks that chatbots do not have, such as poisoned long-term memory, compromised tools in the supply chain and messages between agents that can be forged. In short, chatbot security limits what a system says; agent security limits what it can do.
Which actions should an AI agent never take without human approval?
As a starting point, require approval for actions that send data outside the company, delete data, spend money or change permissions.
Sending externally includes emails to customers, messages to partners and uploads to third-party systems, because a hijacked agent most often tries to leak data this way. Deletion and payments are hard or impossible to reverse. Permission and configuration changes should usually stay with people entirely, with the agent allowed to draft a request but not execute it. Lower-risk actions can run with logging: reading non-sensitive data, or writing small internal updates such as a ticket status.
Reading sensitive data can be allowed within the requesting user's own rights, with every access logged. This matrix is an editorial proposal, not a formal standard. Regulated industries may need stricter rules, and approval requirements can be relaxed for a specific action once logs show the agent handles it reliably over time. Whatever the final rules, write them down per agent and review them after any incident.
Do I need an AI agent security platform?
Not always at the start, but most organizations need one once agents multiply or act on production systems.
For a single pilot agent, well-designed permissions, a sandbox, approval steps and the existing logging stack may be enough. The need for dedicated tooling grows when several teams build agents independently, when agents act for many users, or when auditors ask for evidence of control. Dedicated tooling usually falls into one of four categories: runtime protection, identity and access for agents, posture and discovery, or observability and logging. To choose, start from the gap rather than the vendor.
Then compare products on six criteria: whether they discover unregistered agents, support per-tool permissions, block risky actions at runtime instead of only alerting, export audit logs, integrate with the current identity provider and SIEM, and keep data in an acceptable location. Be cautious with published rankings, since most are written by vendors. A short pilot on one real agent is the most reliable test.
