Services / 03
AI & Agent Security
Agentic systems behave less like applications to be scanned and more like operational estates to be instrumented, governed and monitored. We threat-model them, design the runtime boundaries where privilege is actually exercised, and make their behaviour observable to the people held responsible for it.
The problem
An agent with persistent memory, tool access and its own identity is not an application. It is a principal that reasons over untrusted content and then acts with legitimate credentials. Conventional application security assumes the code path is the attack surface; here the attack surface is the content the system reads, and the exploit is a decision rather than a memory corruption.
This breaks SOC assumptions in a specific and reproducible way. The malicious action is performed by a sanctioned identity, through a sanctioned tool, in an unremarkable session. Where persistent memory is involved, the write that caused it may sit days or weeks outside any correlation window. Nothing in the sequence is anomalous in isolation; the anomaly is a relationship between events that no pipeline currently joins.
Capabilities
What this pillar covers.
Grouped by the part of the system they act on.
Architecture & assessment
- AI security architecture
- AI threat modelling
- AI security assessment
- Agentic system architecture
Runtime
- Agent security
- Runtime policy
- Memory security
- Tool & MCP security
- Agent identity
Observability
- AI observability
- Agent observability
- Behavioural detection
- SIEM integration
Governance
- AI governance
- Model & data governance
- Human approval design
Approach
How an engagement runs.
The sequence matters more than the tooling. Skipping a stage moves its cost later, it does not remove it.
- 01
Inventory
Establish what agents exist, what they can reach, and under whose identity. In most estates this list is longer than expected and shorter than the one in the architecture diagram.
- 02
Threat model
Work the specific system: prompt and memory injection paths, tool privilege, identity collapse, data exfiltration routes, and what an attacker gains at each boundary.
- 03
Design controls
Place policy where privilege is exercised — at the tool boundary, at memory recall, at the identity used for downstream calls — and define which actions stop for a human.
- 04
Instrument
Emit the telemetry a SOC would need to reconstruct an incident after the fact, and write the detection content that runs against it.
What you receive
Concrete artefacts, in your repositories and your platforms.
- A threat model for the specific agentic system, not a generic LLM risk list
- An inventory: agents, tools, MCP servers, memory stores, identities and the privileges behind each
- Runtime policy design — what is allowed, what requires review, what is quarantined, and where the gate sits
- Memory governance: provenance on write, policy evaluated at recall, and a recorded trail of both
- Telemetry design that makes agent reasoning, retrieval and tool calls first-class security events
- Detection content for agent behaviour, delivered into the SIEM your SOC already runs
Expected outcomes
Properties of the resulting system — not performance figures, which depend on your estate rather than on us.
- A concrete inventory of agents, tools, memory stores and the privileges behind them
- Policy enforced at the boundaries where privilege is exercised, not only at the prompt
- Memory treated as governed data — provenance on write, policy at recall
- Agent activity visible in the SIEM the SOC already operates
- A stated position on which agent actions require a human, and why