M ManySignal

Guide · ManySignal

The AI Agent Security Guide

AI agents inside enterprise environments are now first-class actors — they hold credentials, call APIs, touch data, and act on behalf of users at machine speed. Existing SOC tooling was designed for humans and service accounts, not for autonomous agents that can spin up transient identities every few seconds. This guide covers the specific detection and response practices that make AI agents monitorable, containable, and safe to run in production.

DI David Iwu — Staff Engineer, ManySignal
HR Hannah Roth — VP Product, ManySignal
20 min read Published Aug 1, 2026 Download PDF
01

Why AI agents break existing SOC assumptions

Traditional identity monitoring assumes a stable set of humans with predictable patterns and a small number of long-lived service accounts with stable behaviour. AI agents violate every assumption: they proliferate, act at superhuman rates, use tools the operator didn't anticipate, and often chain identities in ways that break blast-radius analysis.

An agent orchestrated by an LLM can, in a single session, assume six different IAM roles, read from three databases, call five SaaS APIs, and drop artefacts in an S3 bucket — all in under 30 seconds. Every one of those actions is legitimate individually and suspicious in aggregate. Detecting this requires a per-agent behavioural baseline, not a per-service-account one.

02

Agent identity: register, tag, baseline

The first requirement is unambiguous agent identity. Every agent should have a dedicated principal (IAM role, service principal, workload identity) that is never shared with a human or another agent. The identity must be tagged with (a) agent purpose, (b) agent owner, (c) autonomy tier, (d) MCP server or framework version.

Once identified, the entity graph tracks agent-specific baselines: hours of activity, target APIs, tool call sequences, error rates, and network egress. Deviations from these baselines are treated with lower tolerance than for humans because the acceptable behaviour space is narrower.

  • Each agent has a dedicated, non-shared principal
  • Agent principal tags: owner, purpose, autonomy tier, framework version
  • MCP server registration includes signed manifest
  • Baseline captures: hours, target APIs, tool sequences, egress destinations
03

MCP server security

MCP (Model Context Protocol) servers are the API surface AI agents call. Every MCP server should be treated as a privileged internal service: TLS-terminated, mutually authenticated, and instrumented with per-call logging. The registered server manifest is the source of truth for which tools an agent can call.

ManySignal ships a native MCP server for security operations — it exposes read-only investigative tools (query graph, fetch case, look up entity) plus a governed set of response tools (isolate host, revoke session) that go through the same autonomy ladder as human-triggered actions.

{
  "jsonrpc": "2.0",
  "id": "req-482",
  "method": "tools/call",
  "params": {
    "name": "manysignal.graph.query",
    "arguments": {
      "entityType": "identity",
      "entityId": "eve@acme.test",
      "window": "24h",
      "include": ["baselines", "recent_events"]
    }
  }
}
04

Detecting agent abuse

Three detection classes handle the majority of agent-abuse cases: (1) tool sequence anomaly — an agent calling tools in an order it never has before, (2) target expansion — an agent touching entities outside its historical baseline, (3) rate anomaly — an agent spiking above its baseline volume in a short window.

Each of these can fire alone benignly (deploys can look like target expansion; incident response can look like rate spikes). The combination — sequence + expansion + rate together — is a near-certain signal of misuse or compromise.

05

Response patterns for agent incidents

The right response to agent misuse is usually not "disable the agent" — that breaks a production workflow. Better patterns: (a) revoke the specific tool that's being abused, (b) drop the agent's blast-radius cap so subsequent actions require approval, (c) rate-limit the agent's principal to below its baseline volume, (d) rotate the agent's credentials.

Kill switch is the last resort. A tenant-level kill switch that halts all agentic action mid-flight exists for the case where the specific compromise scope is uncertain. Practice using it in tabletops — muscle memory matters when the real event happens.

Key takeaways

  • AI agents violate the human/service-account assumption — treat them as a new principal class with their own baselines.
  • Register every agent with a dedicated principal, owner tag, and autonomy tier.
  • MCP server manifests are the source of truth for allowed tools.
  • Three detection classes cover most abuse: tool sequence anomaly, target expansion, rate spike. Combination is decisive.
  • Prompt injection detection is porous; behavioural baselining is not.
  • Practice the kill switch in tabletops — muscle memory matters when it counts.

Further reading

Frequently asked questions

What is The AI Agent Security Guide in an agentic SOC?

The AI Agent Security Guide is part of ManySignal's agentic SOC and MDR platform, where AI agents detect, triage, investigate, and respond to threats with human-governed autonomy.

How does ManySignal handle the ai agent security guide?

ManySignal grounds the ai agent security guide in a temporal entity graph and behavioural baselines, so every verdict is backed by auditable evidence rather than opaque scores.

Can ManySignal replace my SOAR or MDR for the ai agent security guide?

Yes. ManySignal combines detection, triage, investigation, response, and reporting in one platform, and can operate as your MDR or augment an existing SOC team.

How is autonomy governed?

Through an autonomy ladder: recommend-only, approve-gated, and autonomous modes per action class, with dry-run previews, blast-radius limits, and a one-click tenant kill switch.

How fast is time to value?

Declarative connectors and shipped detections typically produce AI agent verdicts on live alerts within days, not quarters — no parsing projects or playbook-building phase.

Is ManySignal available as a managed service?

Yes. Consume ManySignal as MDR with 24/7 coverage and monthly reporting, run it as your in-house agentic SOC, or use it as the platform behind your own MDR practice.

How does ManySignal license the platform?

Pricing scales with protected assets and autonomy tier, not per-GB ingestion or per-alert volume. Starter, Growth, and Enterprise plans are available; MDR providers receive volume discounts for multi-tenant deployments.

Where does our data reside?

By default in AWS us-east-1. Enterprise tenants can pin data to specific AWS regions, deploy self-hosted on their own Kubernetes cluster, or use customer-managed encryption keys (CMK) to retain cryptographic control.

What does the evidence trail contain?

Each verdict stores the full question set, per-question agent answers, confidence weights, source event references, entity graph snapshots, and operator attestation — preserved immutably for the retention period chosen at contract time.

How does ManySignal handle a false-positive alert?

The triage agent auto-closes findings it assesses as false positives with a documented rationale — which rule fired, why the evidence fails to support escalation, and the entity baseline that informed the decision. Auto-closure rates typically reach 85–95% within 90 days as baselines mature.

Continue reading

See the agentic SOC in action

Watch AI agents work a real alert queue — verdicts, evidence, and confidence scores included. In-house SOC or MDR, your call.