AckuityRequest assessment AI AGENT SECURITY GUIDE
AI security protects AI systems, their data, models and applications. AI agent security adds the risks of autonomous action: which tools an agent may use, whose authority it carries, what it changes and when an action must be stopped.
| Evaluation question | AI security | Additional agent-security concern |
|---|---|---|
| What is protected? | Models, training and application data, prompts, outputs and infrastructure | Tool use, delegated authority, action sequences and downstream changes |
| What might go wrong? | Data exposure, insecure applications, model manipulation and harmful output | Unauthorized payments, destructive commands, data extraction and unsafe delegation |
| Where is a decision enforced? | At the relevant model, application, data or infrastructure boundary | Also before the action reaches its tool or target system |
| What evidence matters? | Security findings, protected data and tested application boundaries | Action verdicts and downstream proof that denied operations did not execute |
| How do the disciplines relate? | The broader security discipline | An extension for systems that can take actions, not a replacement |
THE SCOPE
AI security is the wider discipline. An AI agent still needs model, data, application, identity and infrastructure security. When it can act, it also needs controls for tool use, delegation, action sequences and changes to downstream systems.
Ackuity, the Agent Execution Control Switch, focuses on decisions before agent actions run. The Agent Security Context Graph connects the user, agent, intent, target, tools and history for that decision.
FROM ANSWER TO ACTION
A customer-service assistant can explain a refund policy correctly and still call a tool with the wrong recipient account. Protecting the answer and authorizing the payment address different failure modes. This hypothetical example shows why an action needs its own security decision.
Prompt injection is one route to unsafe action, but ordinary mistakes, excessive permissions and task drift also matter. A safe-looking sequence of tool calls can create a harmful result.
COVERAGE
Ackuity describes 11 action types. Three are the LLM, MCP and API calls routed through their gateways; eight action types never reach those gateways in this deployment model: CLI commands, raw HTTP probes, SQL queries, IMDS metadata calls, credential searches, memory writes, RAG retrieval and agent-to-agent hand-offs.
Keep the 8-of-11 distinction tied to the routing model. A gateway can inspect traffic routed through it, and architectures differ. Assess the actual enforcement paths instead of assuming that every gateway has the same coverage. See Ackuity and AI gateways.
EVALUATION
Combine least-privilege identity, secure tools, sandbox boundaries, model safeguards, action authorization and evidence for investigation. Require clear failure behavior and a way to terminate an unsafe agent. Framework mappings describe coverage; they are not certifications.
Use the Ackuity threat models, execution-control definition and kill-switch video and transcript to structure an evaluation.
QUESTIONS PEOPLE ASK
It is a specialization within the broader discipline. Agents still need model, application, data and infrastructure security, plus controls for actions and delegated authority.
No single layer covers every failure mode. An action can be unsafe because of its permissions, target or task context even when its prompt and output look acceptable.
No. Ackuity adds execution decisions and context alongside identity systems, gateways, model guardrails and other security controls.
NEXT STEP
Show us the actions you need to control, and we’ll show you where Ackuity fits.