Skip to content
Aelsha Innovations

Consulting · Agent security

An AI agent threat model: how agents get attacked, and how to defend them.

An AI agent acts in your systems, and it can be tricked by what it reads: an email, a document or a web page. You need to know what it could be made to do, and what stands in the way.

  • A written list of the ways your agent could be misused, ranked by risk, with what we did not examine stated
  • Those risks tested the way an attacker would, with your written permission
  • A plan of fixes, in order, that your team can act on
What the report looks like ↓
Talk to us about your agentsSee the threat matrix ↓

Tell us what your agents do and what they touch. We reply by email.

AI agent security differs from model security because agents act: they call tools, hold credentials and read untrusted content. This page sets out ten threats with one-line mitigations, mapped to the OWASP Top 10 for Agentic Applications, the MCP specification and MITRE ATLAS. Aelsha Innovations offers threat-model reviews, red-teaming, MCP audits and governance work.

Technical detail: standards, methods and what we check ↓
Terms used on this page
AI agent
software that reads a request, decides what to do and acts in your systems.
Threat model
a written map of how an agent could be attacked or misused, and the defence against each.
Prompt injection
hostile text in something the agent reads (an email, a document, a web page, a tool's reply) that tries to give it new instructions.
Red-teaming
attacking a system, with written permission, to find weaknesses before someone else does.
MCP (Model Context Protocol)
the open standard that lets AI agents use your software's data and actions.
MCP server
a small service that offers one of your systems to agents as named actions and data, within limits you set.
Least privilege
each agent reaches only what its one job needs.
Sandbox
a sealed space where code runs with no access beyond what it is given.
OWASP
a non-profit that publishes widely used lists of software security risks.
Governance
the rules for what may run, who approved it, and the evidence kept.

An agent and everything it touches, with four layers of defence. A method, not a live system.

What the diagram shows
  • A person asks the agent to do something.
  • The agent plans and acts. It reads content it cannot trust: pages, files, emails and tool output.
  • It keeps memory between sessions.
  • It calls tools and MCP servers, and exchanges messages with other agents.
  • Least privilege: narrow, short-lived access at every connection (the keys).
  • A person approves consequential actions before they run (the gold node).
  • Tools and generated code run inside a sandbox (the dashed boundary).
  • Every step is traced and kept as evidence (the lane along the bottom).

Our point of view

An AI agent is software that reads untrusted text and then acts. Security for agents is therefore the discipline of deciding, outside the model, what that agent is allowed to do after it has read something it should not trust.
  1. 01

    A model cannot reliably tell instructions from data inside its own context. Controls that depend on the model behaving are advisory; controls enforced outside the model are binding.

  2. 02

    The size of the risk is set by what the agent can do, not by how clever the attack is. Narrow authority limits the damage when something else fails.

  3. 03

    Agents extend the attack surface into tools, memory, other agents and the people who approve their actions. Each is a place to put a control and to collect evidence.

  4. 04

    No set of controls removes risk. The aim is to make failures small, visible and recoverable.

The standards point the same way: the OWASP Top 10 for LLM Applications 2026 moves Excessive Agency to third place, up from sixth in the 2025 list. Source: OWASP Top 10 for LLM Applications 2026

The threat matrix: ten threats to AI agents

Most attacks on an agent work by getting it to read something hostile and then act on it. The ten threats below cover where that happens: the content it reads, its tools and credentials, MCP servers, memory, other agents and the people who approve its work. Each has a mitigation enforced outside the model.

Diagram: a person, the agent, the content it reads, its memory, and its tools and MCP servers inside a sandbox, plus other agents. The table beside it is the text version.

  • Where the threat strikes
  • The defence that stops it

Select a threat in the table to see where it strikes on the diagram. Tab or arrow keys move between threats; Escape clears.

Ten threats to AI agents: where each one strikes, how to mitigate it, and the framework entries it maps to.
ThreatWhere it strikesMitigationFramework reference
AT-01Goal hijack through indirect prompt injectionContent the agent reads. Web pages, files, emails or tool output carry hidden instructions that redirect the agent’s goal.Treat everything the agent reads as data. Enforce an action policy outside the model, keep planning apart from untrusted content, and log any change of goal.ASI01 · MCP06 · AML.T0051
AT-02Tool misuse and excessive agencyThe tools the agent calls. A legitimate tool is used in a harmful way, or the agent holds more tools than its task needs.Give each task the fewest tools it needs, read-only by default. Check arguments against allow-lists and schemas, and cap spend, rate and volume.ASI02 · MCP02
AT-03Identity and privilege abuseThe agent’s credentials. The agent borrows a person’s or a service’s standing access and goes beyond its remit.Make the agent its own non-human identity with short-lived, narrowly scoped tokens, and require step-up authorisation for sensitive actions.ASI03 · MCP01, MCP02, MCP07
AT-04Confused deputy and token passthroughMCP servers that act as proxies. A proxy acts with authority the caller never granted, or accepts tokens that were not issued to it.Ask each client for consent before third-party authorisation, accept only tokens issued for this server, match redirect URIs exactly and validate state.MCP spec: Confused Deputy Problem, Token Passthrough · MCP07
AT-05Tool poisoning and rug-pullTool definitions on MCP servers. A tool description is malicious from the start, or changes after it was approved.Pin and hash tool definitions, require re-approval on any change, and scan servers before and after install.ASI02 (ASI04 only if the tool is compromised at source) · MCP03, MCP04
AT-06Agentic supply-chain compromiseUpstream components. A model, library, MCP server or prompt template is tampered with before it reaches you.Use signed artefacts and a software bill of materials, audit dependencies, pull through private mirrors, and keep an inventory of every MCP server in use.ASI04 · MCP04, MCP09 · AML.T0010
AT-07Unexpected code executionWherever code runs. Code the agent writes, or a tool supplies, runs with the authority of the host.Run it in a container or microVM sandbox with no network and no secrets by default, and never pass URLs or commands through a shell.ASI05 · MCP05
AT-08Memory and context poisoningThe agent’s memory. Bad content is stored and shapes later sessions, other users or other agents.Tag every memory write with its source, scope memory per user and task, let it expire, review high-impact memories and allow a purge.ASI06 · MCP10 · AML.T0080
AT-09Insecure inter-agent communication and cascading failureMessages between agents. A forged or compromised message spreads, and one fault cascades across agents.Sign messages and Agent Cards, use mutual TLS, authorise at every hop, and add circuit breakers and blast-radius limits.ASI07, ASI08 · MCP07, MCP08
AT-10Human-agent trust exploitation and rogue agentsThe person approving, and the agent’s mandate. An approver is misled by the agent’s own summary, or the agent drifts from what it was asked to do.Show approvers the concrete action or diff, not the agent’s summary. Monitor behaviour, and test the kill-switch in production-like conditions.ASI09, ASI10 · MCP08, MCP09

Data leaving through tools is an outcome of AT-01 to AT-03, and is controlled by egress allow-lists and output checks.

Frameworks in the reference column

Mappings are our judgement of the closest fit, not an official crosswalk. ATLAS technique IDs are re-checked against the live matrix before each publication.

Eight principles we build and review against

These are the rules we hold agent systems to, whether we are building one or reviewing yours. Each one moves a control out of the model and into something you can enforce, test and audit.

  • Least privilege per task

    Narrow tools, scoped short-lived credentials, and no standing access the task does not need.

  • People approve consequential actions

    Irreversible, financial or external-facing steps need explicit approval of the actual action.

  • Untrusted by default

    Everything the model reads, tool output included, is data. Policy is enforced outside the model.

  • Contain execution

    Sandbox generated code and local servers. Deny network access and secrets by default.

  • Validate in both directions

    Schema-check tool arguments, and check outputs before they reach any downstream system.

  • Know what is running

    Track where models, tools, servers and memory writes come from. Prefer pinned, signed components.

  • Test adversarially and continuously

    Threat-model, red-team before launch, and use evaluations as release gates, against real services rather than mocks.

  • Observe and keep evidence

    Trace every plan, tool call and approval with the OpenTelemetry GenAI conventions (Development status), and keep tamper-evident audit logs.

Source: OpenTelemetry GenAI semantic conventions

What good looks like at each autonomy tier

The more an agent may do on its own, the more evidence it should show first. AELSHA™ ASTRA defines four autonomy tiers and holds that autonomy is earned through demonstrated reliability. Below is the security evidence we expect before an agent operates at each tier. Each tier includes the one before it.

  1. T0

    Assist

    The agent may: Suggest; a person performs every action.

    Evidence before it operates here

    • A threat model exists for the use case
    • Retrieved content and tool output are handled as data
    • Prompts and responses are traced
    • No write-capable credentials are issued to the agent
  2. T1

    Supervised

    The agent may: Act, with a person approving each consequential step.

    Evidence before it operates here

    • Its own identity, with scoped, short-lived credentials
    • An explicit tool allow-list with argument validation
    • Approval screens that show the concrete action
    • Tool definitions pinned and hashed; adversarial test results recorded
  3. T2

    Conditional

    The agent may: Act alone within defined limits, and escalate outside them.

    Evidence before it operates here

    • Spend, volume, scope and time limits enforced outside the model
    • Sandboxed execution; memory writes tagged, scoped and expiring
    • Behavioural monitoring with alert thresholds
    • A tested kill-switch and rollback; a release gate re-run on every change
  4. T3

    High

    The agent may: Act with broad independence, with review after the fact.

    Evidence before it operates here

    • Continuous adversarial evaluation in a real pre-production environment
    • A tamper-evident audit trail reviewed on a schedule
    • Independent review of the threat model and a rehearsed incident response
    • Demotion criteria; promotion stays a recorded human decision

No tier is safe in itself. Each tier states what evidence supports the autonomy granted.

About AELSHA™ ASTRA →Framework · delivered through engagements

Agent security services

Fixed-scope engagements, each ending in something you keep. How long each takes depends on what is in scope, so we agree the scope and the schedule with you at kick-off. The work runs against your real systems or a faithful pre-production environment, never mocked services, and every finding comes with the evidence to reproduce it in your own environment.

  • Agent threat-model review

    Scope: One agent or one multi-agent workflow: its tools, data, memory, identities and approval points, scored against the ten threats.

    You receive

    • Threat model
    • Ranked risk register
    • Control-gap table
    • 90-day remediation plan
    • AELSHA™ ASTRA autonomy-tier recommendation
    • What we did not examine, stated in the report

  • MCP server security audit

    Scope: One MCP server, your own or a third-party one you plan to adopt, deployed in an environment you own, with its client configuration and authorisation setup, tested on that real instance with your written authorisation.

    You receive

    • Findings referenced to the MCP specification and the OWASP MCP Top 10
    • Fixes ordered by effect
    • Pinning baseline of tool definitions
    • Re-test of fixed items
    More on MCP engineering →

  • Red-team and adversarial evaluation

    Scope: A deployed agent in a real pre-production environment, with real tools in isolated tenants, under written authorisation and agreed rules of engagement.

    You receive

    • Test plan and rules of engagement
    • Reproducible findings with fix guidance
    • A regression suite you run each release
    • Retest report

  • A2A interoperability security review

    Scope: Agents exchanging tasks over A2A: Agent Card publication, authentication and delegation, tested hop by hop in a real multi-agent environment.

    You receive

    • Trust-boundary map
    • Findings
    • Agent Card signing and key-rotation recommendation
    • Per-hop authorisation policy

  • Agent identity and authorisation design

    Scope: How agents, tools and people are identified and what each may do: the agent as its own principal, scopes, token lifetimes, step-up and delegation.

    You receive

    • Identity and scope model
    • Policy definitions
    • Step-up and revocation runbook
    • Working reference configuration in your identity provider

  • Governance evidence pack

    Scope: The evidence that shows an agent is governed: AI inventory and risk tiering, mapped to the AI management-system standard, the EU AI Act where relevant, and India’s DPDP Rules.

    You receive

    • Inventory and risk tiering
    • Control-to-evidence matrix
    • Audit-trail specification built on OpenTelemetry traces
    • Gap list and evidence folder structure

    This is technical and evidence work, not legal advice. Whether and how a law applies to your system is for your legal counsel to decide.

What the report contains (agent threat-model review)
  • A threat model of your agent or workflow: its tools, data, memory, identities and approval points, scored against the ten threats
  • A ranked risk register
  • A control-gap table
  • A 90-day remediation plan
  • An AELSHA™ ASTRA autonomy-tier recommendation
  • What we did not examine, stated in the report

Related work

Know where your agent is exposed

Tell us what your agent can do and what it touches. A threat-model review gives you a ranked risk register and a plan you can act on.

Talk to us about your agents