Security of AI agents

Agents break the assumptions your controls were built on

Application security assumes code paths are known in advance. Access governance assumes a human requests, a manager approves, and a reviewer certifies. Agentic systems break both: they combine reasoning, persistent memory, tool access and multi-step execution, so the sequence of actions is decided at run time and shaped by whatever text the agent happened to read.

The result is a failure class of its own. An agent can be talked out of its original objective by content it retrieves. It can be given a legitimate tool and induced to use it in an illegitimate combination. Its memory can be poisoned so a bad instruction persists across sessions. And because agents are provisioned quickly and quietly, they tend to accumulate privilege faster than any review cycle catches.

---

We work to a published threat model

Our assessments are structured around the OWASP Top 10 for Agentic Applications, so findings map to a vocabulary your engineers, your auditors and your suppliers can all read.

Risk	What it looks like in production
Agent goal hijack	Retrieved content redirects the agent away from the task it was given
Tool misuse & exploitation	Legitimate tools called with parameters or in sequences nobody intended
Agent identity & privilege abuse	Shared service accounts, over-broad scopes, no way to attribute an action
Agentic supply chain compromise	A third-party tool, plugin or MCP server that is trusted by default
Unexpected code execution	Generated code or commands reaching a runtime without a sandbox
Memory & context poisoning	A malicious instruction persisted into memory and replayed later
Insecure inter-agent communication	Agents trusting each other’s output without authentication or validation
Cascading agent failures	One bad output propagating through a chain faster than anyone can intervene
Human-agent trust exploitation	Confident output that an operator approves without real review
Rogue agents	Agents running outside inventory, oversight or termination procedures

---

What we do

Agent threat modelling and architecture review

We map each agent’s objective, inputs, memory, tools, autonomy level and blast radius, then work through where trust is being assumed rather than established. The output is a ranked set of findings with concrete design changes, not a list of generic warnings about prompt injection.

Agent identity and entitlements

This is where our identity governance background pays off directly. Agents should have their own identities with named human owners, narrowly scoped and time-bound credentials, delegation that carries the invoking user’s authority rather than exceeding it, an entry in the joiner-mover-leaver process, and inclusion in access certification. Most organisations have none of that yet.

• Non-human identity model covering agents, tools and service connections
• Least-privilege scoping per tool, with credentials that expire and rotate
• Ownership, lifecycle and decommissioning — including how an agent gets switched off
• Attribution: proving which agent, on whose behalf, did what

Tool and supply-chain assurance

Every tool an agent can call is an extension of your attack surface, and connector ecosystems such as MCP servers are being adopted faster than they are being reviewed. We assess what a tool can reach, how it authenticates, whether its description can itself carry an injection, and what a compromised or substituted version would allow.

Guardrails, sandboxing and human-in-the-loop

Not every action deserves the same level of autonomy. We design the tiering — what an agent may do freely, what requires a second signal, what requires a human approval that is meaningful rather than a reflex click — plus execution sandboxing, rate and spend limits, and circuit breakers that stop a cascade before it compounds.

Red-teaming and evaluation

Adversarial testing against your actual agents: indirect prompt injection through documents, web pages and tickets; tool-chaining abuse; memory persistence attacks; and privilege escalation across agent boundaries. Findings come with reproductions and regression tests you can run in CI, so a fix stays fixed.

Governance and regulatory alignment

An AI inventory, risk classification, approval gates and the documentation that regulators and enterprise customers now ask for — aligned to the EU AI Act, ISO/IEC 42001 and the NIST AI Risk Management Framework. Note that the AI Act’s transparency obligations under Article 50 apply from 2 August 2026, while the timeline for high-risk system obligations has been deferred under the Digital Omnibus; we will help you work out which of your systems fall where, and what that means in practice.

---

What you receive

• An agent inventory with owners, autonomy levels, tools and data reach
• A threat model and ranked findings mapped to the OWASP agentic risks
• An agent identity and entitlement design that fits your existing IAM and IGA
• Guardrail and approval architecture, with the autonomy tiers written down
• Red-team results with reproductions and regression tests
• Governance artefacts: policy, risk classification and the evidence to support it

Common questions

We are only running a few internal agents. Is this premature?

It is the best possible time. Getting agent identity and approval tiers right while you have five agents costs a fraction of retrofitting it across fifty — and the pattern you establish now is the one the rest of the organisation will copy.

Does this require access to our models?

No. We work at the level of architecture, identity, tools, permissions and observability, which is where the exploitable risk concentrates. That applies whether you use a hosted model, a self-hosted one, or several.

Can you work with our developers rather than around them?

That is the intended shape. The engagements that stick are the ones where the guardrails are built with the team that ships the agents, and where the regression tests end up in their pipeline rather than in our report.