AI agent security
AI agent security protects the software, identities, data, and connected systems involved when an agent acts. Its scope includes malicious inputs, compromised dependencies, stolen credentials, and misuse of legitimate capabilities.
Ask what an attacker could make the application do. A harmless-looking response doesn't tell you whether the application also exported data without permission or made an unwanted change. The OWASP Top 10 for Agentic Applications separates risks involving goals, tools, identity, supply chains, memory, and communication.
Explore Dome: Dome Platform · Docs: Security tutorial.
Start with what the agent can do
Suppose a research agent reads supplier documents, compares prices, and drafts a purchase recommendation. It reads uploaded documents, search results, and tool descriptions. It may also read files, send queries, and use purchasing tools available to the application.
Supplier documents can influence the agent's recommendation. A purchasing credential can let it place an order. A third-party package may access data or credentials in the runtime. Include each of these in the security review.
“Excessive agency” describes a mismatch between the application's assigned work and the capability or autonomy it has been given. A recommendation agent that can place orders has a larger potential impact than one that can only write a draft. A single command-execution tool may let the application perform many different actions.
Agentic supply-chain security examines the packages, tool servers, model services, and other dependencies the agent relies on, including how changes to them are reviewed.
For each input and dependency, ask what an attacker could make the agent read, change, or send.
Explore Dome: Tool Gateway · Docs: Tools gateway.
Choose a control for each risk
| Risk in this example | Control to evaluate |
|---|---|
| Supplier text redirects the task | Treat retrieved content as untrusted and constrain resulting actions |
| A dependency steals a key | Isolate secrets and restrict the runtime's access |
| A permitted search leaks internal pricing | Restrict outbound fields, destinations, and returned content |
| A tool changes after approval | Review definition and implementation changes |
| A purchase is duplicated after a timeout | Check whether the purchase completed and define when retries are allowed |
Match the test to the risk: test outbound-data controls with a query containing internal pricing, and review package integrity separately. A filter on the model's response won't catch a dependency stealing a credential.
Use prompt injection for instruction manipulation, tool poisoning for tool-definition risks, and credential isolation for how credentials are kept out of the agent runtime.
Explore Dome: Authorization · Docs: Security tutorial.
Test an unwanted action
For the research agent, a controlled test could ask it to place an order when it should only make recommendations. Use synthetic data, record where the instruction entered, and check both the refusal and the backend for any order created. Also confirm that it can still produce an allowed recommendation.
Record the route and conditions tested; a refusal on one route doesn't cover other ways to reach the purchasing system. Repeat the review when capabilities, credentials, or dependencies change.
Dome's Tool Gateway provides a place to apply configured rules and guards to routed tool calls. The surrounding security review still needs the runtime, server packages, data stores, and direct access paths. Mark on the architecture diagram which component handles each check and which requests pass through it.
Explore Dome: Tool Gateway · Docs: Guards.