AckuityRequest access THREAT MODELS / SECURE AI AGENTS
Agent risk lives in tools, memory, permissions and handoffs. See how legitimate-looking steps can cross the boundaries of the task you authorized.
Early access. Already in paid production.
Prepare the vendor renewal summary.
Read contracts · Compare renewal datesAssume finance-admin.
Outside task scope → Hold for reviewFOUR PATTERNS WORTH RECOGNIZING
Ackuity connects proposed execution to the task, authority and history behind it. These examples show why those connections matter.
01 / ACTION CHAINS
An agent reads contracts, assumes a finance-admin role and attempts a payment. Each operation has to be judged against the original task.
Task intent + action historySee action chain exploitation02 / SCOPE
An agent can retrieve a document, but the intended recipient may be outside the permitted scope.
Identity + data policy + recipientSee contextual scope bypass03 / MEMORY
A changed memory or retrieved instruction can quietly redirect later work. The final call may look routine in isolation.
Memory + provenance + prior behaviorSee slow state corruption04 / DELEGATION
A downstream agent treats another agent’s request as permission to act. The original user never granted that scope.
Delegation chain + original authoritySee inter-agent exploitationWhich of these patterns could occur in your environment? Start with the agents, tools and permissions you already have.
Request accessTHREAT COVERAGE STARTS WITH YOUR ARCHITECTURE
Use the catalog to ask better questions about your agents. It covers risks across identity, tools, memory, MCP, data and policy. A listed threat is an assessment topic, not a promise of automatic prevention.
53 threats in 14 categories
Risks in trust, authentication and decisions shared between agents.
Corruption of the information an agent stores or retrieves as context.
Behaviour that departs from intended goals or presents a misleading appearance of alignment.
Misuse of permissions, roles or delegated authority.
Generated instructions or operations that introduce executable attacks.
An agent or user is represented as someone other than the authenticated actor.
Actions designed to influence users or conceal activity.
Agent behaviour that exhausts compute, quotas or execution capacity.
Disclosure of protected information through agent activity.
Unsafe tools, compromised dependencies or harmful combinations of otherwise available operations.
Inputs that attempt to redirect an agent from its authorized task.
Attacks on the effectiveness of human oversight and intervention.
Risks at Model Context Protocol integrations and connected servers.
Actions that cross defined access or information handling boundaries.
ACKUITY RESEARCH
Four broad classes. 21 threat vectors.
BRING A FRAMEWORK TO YOUR SECURITY REVIEW
Use our research to structure your assessment, then connect it to the tools, identities and data your agents actually touch. The expanded catalog above provides additional topics to investigate.
Read the researchPUT CONTEXT TO THE TEST
Try three illustrative agent-action scenarios. Find the context that changes the decision.
YOUR QUESTIONS, ANSWERED
AI agent risks include prompt injection, unsafe tool use, memory poisoning, privilege misuse, sensitive data exposure and compromised delegation. Assessing them requires looking at the agent’s permissions, connected systems and sequence of actions, as well as its inputs.
A prompt can be legitimate while a later action exceeds the task’s scope. For example, preparing a finance summary does not authorize a role change or payment. The relevant checks include intent, identity, permissions and earlier actions.
An MCP gateway can govern access and calls through that gateway. Agent security also requires understanding why a call is being made, what scope was delegated and how it relates to activity elsewhere. The controls needed depend on your architecture.
No. The catalog describes risks to assess, not a universal prevention guarantee. Detection and enforcement depend on available context, policy and the integrations in place. Read-only discovery surfaces findings without blocking execution.
NEXT STEP
Start with read-only discovery. Leave with findings your engineering and security teams can act on.