Agent Security for AI-Powered Cybersecurity Workflows
Agent Security is the practice of protecting AI agents from unsafe tool use, prompt injection, data leakage, privilege misuse, and uncontrolled automation when they interact with real systems such as SIEM, SOAR, EDR, threat intelligence platforms, and ticketing tools.
Why Agent Security matters
AI agents in security workflows are highly privileged callers. They sit in front of containment, blocking, and notification systems. A compromised or manipulated agent does not just produce a bad answer — it changes infrastructure state, silences alerts, or exfiltrates investigation context through tool arguments.
How it works
Agent Security puts a deterministic boundary between the agent's reasoning and the tools it can call. The model decides; the boundary enforces. Every tool call is checked against policy, validated against a schema, redacted, and logged before it reaches a real system.
- The agent emits a tool call with arguments.
- A policy engine evaluates the call against allow-lists and scope rules.
- Argument schemas reject malformed or out-of-scope parameters.
- Sensitive fields are redacted on arguments and outputs.
- Consequential tools route to a human-approval gate.
- The call, decision, and result are written to a tamper-evident audit log.
Reference architecture
User/Alert → AI Agent → Policy Engine → Tool Permission Layer → MCP Tools (SIEM/SOAR/EDR) → Logging & Audit Layer.
Common risks
- Prompt injection via untrusted content steering the agent toward unsanctioned tools.
- Scope escalation — legitimate tools called with out-of-scope arguments.
- Exfiltration through tool arguments — sensitive context encoded into URLs or webhook fields.
- Confused-deputy abuse — the agent's identity used to do what the caller could not.
- Audit erasure — agents failing without a structured record.
Security controls
- Scoped tool surface per agent persona
- JSON-schema argument validation
- Deterministic policy engine at the call boundary
- Approval modes for consequential tools
- Field-level redaction
- Tamper-evident, replayable audit log
Concrete agent-security scenarios
Agent tries to call an unauthorized tool
An injected instruction tells the agent to invoke user.disable, which is outside its allow-list. The policy engine rejects the call before any network request and logs the attempt.
Prompt injection tries to exfiltrate data
A malicious alert body instructs the agent to append case notes to a ti.lookup URL. Argument validation and redaction strip the payload; the exfil attempt is blocked and flagged.
Agent attempts a SOAR action without approval
The agent recommends edr.isolate. Because isolation is a consequential tool, the call is held at the approval gate until an analyst authorizes it.
Agent over-queries threat-intel APIs
A loop causes the agent to call ti.lookup hundreds of times. Per-identity rate caps throttle it and raise an alert, protecting the paid API and the budget.
Agent reads sensitive case notes without need
The agent requests a field it has no task-need for. Scope rules deny the read, and the access attempt is recorded for review.
Confused-deputy tool call
A low-privilege user prompts the agent to perform an action only admins can do. The policy engine evaluates the operator identity, not just the agent's, and denies it.
Mistakes to avoid
- Giving the agent a flat, undifferentiated tool surface.
- Trusting the model to self-redact instead of redacting at the boundary.
- Treating prompt-injection detection as the whole of agent security.
- Logging tool names but not arguments, outputs, or approvals.
- Automating consequential actions to chase throughput.
Related projects
Related research
Related services
Frequently asked questions.
What is Agent Security?
How is Agent Security different from prompt-injection defense?
Where should the guardrail layer sit?
Do Agent Security controls require an LLM specialist?
Build agents that earn their privileges.
See the projects and case studies that put these controls into production, or get in touch to compare notes.