An Agent Is a Privileged User That Can Be Argued With

It holds credentials, calls tools, and makes decisions. Its instructions arrive from whoever it happens to be reading.

Why Agents Change the Risk Calculation

A chatbot that gives a wrong answer is a support problem. An agent that takes a wrong action is an incident. Then you grant it tools: refund a customer, update a record, query a database, send an email, open a pull request, call an internal API. At that point every weakness in the model becomes a weakness in your business process.

What makes this genuinely new is the trust model. Agents cannot reliably distinguish data they are processing from instructions they should follow. Any content an agent ingests becomes a potential command channel: a customer message, a support ticket, a scraped web page, a PDF, another agent's output. Your authorization model was designed for humans clicking buttons. It was never designed for a service account that can be talked into things.

Public-facing agents are reachable by every attacker on the internet, unauthenticated
Tool permissions are almost always broader than any single task requires
Actions execute in seconds, at machine speed, with no human review step
Agent activity looks legitimate in logs because the agent is authorized
Multi-agent systems trust each other's output implicitly, so one compromise propagates
Agent privilege reality check
Who can reach it

Anyone on the internet, unauthenticated, in plain language. No account and no exploit required.

What it holds

Standing credentials to your CRM, billing, ticketing, and internal APIs, usually as one shared service account.

What it can do

Issue refunds, change records, query databases, send mail, call other agents. In seconds, without review.

What you would see

Authorized activity from an authorized identity. Nothing in the logs marks it as an attack.

A privileged user that can be argued with, and never gets tired of being asked.

The Agentic Threat Model

What we test for, and what we keep finding in production agent deployments

Indirect Prompt Injection

Instructions hidden in the content an agent consumes: tickets, emails, documents, web pages, API responses. The attacker never touches your agent directly. They leave a message where the agent will find it and obey it.

Excessive Agency

Agents provisioned with broad, standing permissions "so they don't get stuck." We map what each tool can reach and demonstrate the gap between the task the agent was built for and the damage it's capable of.

Tool & Function Abuse

Chaining legitimate tools into illegitimate outcomes: read a record with one, transform it with another, exfiltrate it with a third. Each call is authorized in isolation; the sequence is what causes the breach.

MCP & Connector Trust

Model Context Protocol servers and third-party connectors are supply chain. We review server provenance, tool-description poisoning, credential scoping, and whether a malicious or compromised connector can reach beyond its intended boundary.

Agent Identity & Authorization

Does the agent act as the requesting user, or as an all-powerful service account? We test identity propagation, delegation, token scope and lifetime, and whether authorization is re-evaluated at the moment of action.

Memory & State Poisoning

Persistent memory turns a one-time injection into a lasting backdoor. We test whether attacker-supplied content can survive in agent memory, vector stores, or shared context and influence future sessions and other users.

Multi-Agent Trust Failures

Orchestrators that accept sub-agent output as fact. We test whether one compromised or manipulated agent can escalate through the swarm, forge task results, or trigger privileged actions in a peer.

Denial of Wallet

Agents that loop, recurse, or can be goaded into expensive tool and inference calls. Unbounded autonomy is a financial availability risk, and cost controls are frequently the only guardrail nobody implemented.

Missing Audit & Detection

When an agent is manipulated, can you prove what happened? We check whether prompts, tool calls, and decisions are logged immutably, attributed to a human principal, and actually reaching your SIEM.

Agents We Test

Customer-facing or internal, single-purpose or fully autonomous

Customer Support & Service Agents

The highest-exposure deployment in most businesses: an autonomous agent handling your customer pipeline, connected to order systems, billing, and CRM, talking to strangers all day. We test it the way a fraudster would.

Transactional & Commerce Agents

Agents that quote, order, refund, provision, or move money. Every one of these is a business-logic attack surface where a successful manipulation has an immediate dollar value attached.

Internal Operations Agents

IT, HR, and finance automation with access to identity systems, ticketing, and records. A manipulated internal agent is an insider threat that never sleeps and never questions an instruction.

Coding & DevOps Agents

Agents with repository, CI/CD, and cloud access. Injected instructions in an issue, dependency, or README can become committed code, a poisoned pipeline, or leaked secrets, at the speed of automated review.

Research & Browsing Agents

Anything that autonomously fetches and reads web content is executing untrusted input by design. We test how far a hostile page can steer the agent and what it can reach once it does.

Multi-Agent Orchestration

Planner-executor architectures, agent swarms, and frameworks like LangChain, LangGraph, CrewAI, AutoGen, and Bedrock Agents. We assess them as distributed systems with trust boundaries.

How the Engagement Runs

Two to four weeks from kickoff to a report your engineers can act on

1

Architecture Review

We inventory every agent, tool, connector, data source, credential, and identity, then diagram the trust boundaries. This alone surfaces over-permissioned tools and missing approval gates before any testing begins.

2

Abuse-Case Design

With your team we define what "worst case" means for this agent: unauthorized refunds, PII disclosure, privilege escalation, code execution. Objectives get designed around those outcomes instead of a generic checklist.

3

Adversarial Execution

Direct and indirect injection through every ingestion path, tool-chain abuse, identity and authorization testing, memory poisoning, and multi-turn manipulation, all run by hand.

4

Guardrail & Detection Testing

We evaluate whether your filters, policy models, approval gates, and rate limits hold under pressure, then check whether anything the agent did generated an alert your SOC would investigate.

5

Reporting & Architecture Fixes

Reproducible findings with full transcripts, an executive narrative, and a remediation plan centered on containment by design: scoped tools, per-user identity, action-level authorization, and human approval where it counts.

6

Re-Test & Regression Suite

A free re-test within 90 days, plus an optional regression suite your team can run in CI so the next prompt, tool, or model change doesn't quietly reopen what you just fixed.

Agentic AI Security FAQ

Read-only removes the transaction risk and leaves the disclosure risk untouched. "Read-only" is also rarely accurate once you trace what the retrieval layer can reach. The two questions we ask first: can the agent read anything the current user shouldn't, and can it transmit what it reads (a link, an image, a tool call, an email)? If both are true, you have an exfiltration path regardless of write permissions.

Guardrails raise the cost of an attack; they don't eliminate the class. They are probabilistic filters facing an attacker with unlimited attempts and infinite phrasings. Encoding, translation, indirection, and multi-turn setup all get past them regularly in our testing. Treat guardrails as one layer, and put the real controls where they're deterministic: scoped tool permissions, per-user identity, authorization checks at execution time, and human approval on irreversible actions.

Yes. We regularly assess LangChain and LangGraph, CrewAI, AutoGen, OpenAI Assistants and Agents, Anthropic tool use and MCP servers, Amazon Bedrock Agents, Azure AI Foundry, and Google Vertex AI Agents, as well as fully custom orchestration. The framework changes the implementation details; the trust boundaries and the testing objectives stay the same.

A staging environment with the real tool chain and synthetic data is ideal, because the tools are the risk and stubbing them out defeats the purpose. In production we operate under explicit rules of engagement: destructive tools are excluded or redirected to test records, we stop at proof of capability instead of completing damaging actions, every prompt is logged for reconciliation, and your team holds a kill switch throughout.

Before launch, and while the architecture is still cheap to change. The most valuable engagement we run is a pre-launch architecture review plus a short adversarial test. Most serious agentic findings are design decisions such as tool scope, identity model, and approval gates, and those get expensive to fix once customers depend on the behavior. After launch, move to continuous assurance as prompts and tools change.

Our AI & LLM security testing covers the whole AI attack surface, including models, retrieval, and applications that primarily generate text. This service is the specialization for systems that take actions: the tool layer, agent identity, orchestration, and autonomy controls. If your AI can change something or spend something, you want this engagement.

Find Out What Your Agent Will Do for an Attacker

Bring us your architecture diagram and a list of the tools your agent can call. Twenty minutes is usually enough to identify the actions that should never have been automated without a gate.

Schedule an Agentic AI Review