Agent and MCP assurance

What it is for

An agent is a model with hands. S2 checks what those hands can reach. It covers one agent system end to end at a fixed depth; the twelve AI agent scopes go deeper on one area each, and can be added to S2 or bought on their own.

What we look at

• Tools: every tool the agent can call, what it can change, and whether the agent needs it.
• Authority: whether tools act as the user, as the agent, or as a shared service account, and how tokens are scoped and passed.
• Sandboxing: where code runs, what it can read and write, and where it can connect.
• MCP servers: the servers in use, their authorization, and the risks the MCP security best practices describe, including confused deputy attacks, token passthrough, server-side request forgery, local server compromise and scope minimisation.^⁠[1]
• Human approval: which actions need a person, and whether the approval screen shows what will actually happen.

The MCP specification itself says tool descriptions such as annotations should be treated as untrusted unless they come from a trusted server, and that hosts must obtain the user’s consent before invoking a tool.^⁠[2] We test whether your system behaves that way.

What you receive

A tool permission matrix (each tool, its authority, its reach, and what we recommend), an OAuth and scope review, a sandboxing review and an MCP server audit, with every finding mapped under the TriOngle Method.

How it runs

Configuration and code review, followed by tests against a test deployment. The CoSAI taxonomy for MCP security, which sets out nearly forty threats in twelve categories, is our checklist for completeness.^⁠[3]