Architecture & Authority Review

A design-time review of how your agent system grants, delegates, and constrains authority: permissions, identity, trust boundaries, delegation, and tool and action architecture. Best for teams that are still designing the system.

Expert service · Design-time

Most authority decisions are made before there is anything to test.

Which tools an agent gets, what identity it acts under, where untrusted content enters, and which actions need a human are design decisions. Reviewing them early is cheaper than testing around them later.

Tools are granted broad permissions by default, with no written record of what each one can reach.
Untrusted content (tickets, documents, tool output) enters the same context that decides privileged actions.
Delegation between users, agents, and downstream systems is implicit and undocumented.
Approval conditions are described in prose but not enforced anywhere the agent can see.

What we review

The review is document- and design-driven; it does not execute the agent.

Permissions
What the agent and each tool are allowed to do, and whether that matches intent.
Identity
Which principal the agent acts as, and how downstream systems know.
Trust boundaries
Where untrusted content enters and what separates it from privileged actions.
Delegation
How authority flows from user to agent to tool to external system.
Tool and action architecture
How tools are exposed, scoped, and gated, including approval points.

How a review runs

A short, human-led engagement scoped to your design documents and a working session with your team.

01
Collect
Architecture notes, tool and MCP definitions, prompts, and the intended authority model.
02
Review
A security researcher reviews permissions, identity, trust boundaries, delegation, and tool architecture against the intended authority.
03
Recommend
Written recommendations, prioritised, with the design change each one implies.

What you receive

Authority model
A written model of who can do what, through which tools, under which conditions.
Findings and recommendations
Design-level issues with the change each one implies.
Assessment readiness
Whether and how the system can be tested with the AI Agent Security Assessment once built.

Expert services are optional additional capacity. A review is not required before an AI Agent Security Assessment.

Why a design-time review

Before the tools are wired
Permissions and boundaries are cheapest to change before they exist.
Same thesis as the assessment
The review applies the same authority-centred method the assessment tests against later.
Researcher-led
Run by a security researcher, not a checklist.

Questions we get asked

Is this required before an assessment?

No. The assessment stands on its own. A review is for teams that are still designing the system.

Does the review execute the agent?

No. It is a design-time review of documents, definitions, and a working session with your team. Execution belongs to the assessment.

How long does it take?

Scoped per engagement; typically a short engagement sized to the design surface.

Still designing the system?

Tell us what the agent will do and how authority is meant to flow. We will scope a review.