Fee
Register to see indicative feesConfirmed in writing after scoping01 / Build & Advisory · Standard
AI Agent Security
Your agents can now take actions in live systems, and nobody is entirely sure what stops them.
Typical duration
6 to 10 weeksScoped in a discovery workshop before anything is quotedPrimary artefact
Agent permission modelPlus 2 moreWho leads it
Steve SharmaFounder & Principal04 / What this is
What AI Agent Security is
A design and control engagement for AI agents: systems that act rather than answer. It establishes what each agent may reach, what it may do, what requires a human, and how you would know if it did something else.
The pricing is Discovery mode because agent estates vary more than any other AI system type. Quoting before scoping would be guessing, and we would rather say that than publish a number we then revise.
05 / Who it is for
Built for a real assurance trigger, not a badge project.
This fits when
- Organisations running agents with write access to production systems.
- Teams building multi-agent or tool-using workflows.
- Anyone whose agents touch customer data or financial systems.
- Security functions asked to approve agent deployments with no framework.
The usual trigger
- An agent has been given write access to a live system.
- A multi-agent workflow is moving to production.
- Someone asked what an agent could do if it were manipulated and nobody knew.
- An agent took an unexpected action.
06 / The obligation
Why agents are a different risk class from models
A model that answers produces text you can review. An agent that acts produces consequences you cannot undo. That is the entire difference, and it changes what security means.
Permissions granted for the happy path
An agent's permissions are usually granted for the happy path, the things you want it to do, while its instructions come from a channel an attacker may influence.
Convinced, not hacked
An agent with legitimate write access to a ticketing system, persuaded to use that access for something else, has not been hacked. It has been convinced.
A narrower boundary on reach
The control that works is not better guardrails on what the agent says. It is a narrower boundary on what the agent can reach.
A human gate on irreversible actions
Actions that cannot be reversed pass through a human gate.
Unusual behaviour treated as a signal
Monitoring treats unusual agent behaviour as a signal rather than as noise.
You cannot prompt your way to a permission boundary. The control that holds is architectural, and it is usually a smaller blast radius rather than a better instruction.
07 / What you receive
Three artefacts. Each one yours to keep.
- 01
Agent permission model
What each agent may reach and do, with the reversibility of each action assessed.
Permission matrixEngineering + risk - 02
Human-in-the-loop design
Which actions require a person, why, and what the person is actually being asked to check.
Design documentProcess owners - 03
Agent monitoring design
What normal looks like, what would indicate manipulation, and where the alerts go.
Detection designOperations
08 / Scope
The whole system is visible before work begins.
Agent inventory
- Agents catalogued with their tool access
- Reachable systems and data per agent
- Action reversibility assessed
Permission design
- Least-privilege permission model
- Blast radius per agent
- Isolation and sandboxing boundaries
Human gates
- Actions requiring human approval
- What the human is checking, specifically
- Escalation and override paths
Monitoring
- Normal behaviour baseline
- Manipulation indicators
- Alert routing and response
09 / Included / not included
A useful boundary is part of the deliverable.
Included
- Agent inventory
- Permission design
- Human gate design
- Monitoring design
Not included
- Implementation: We design the boundaries. Enforcing them in code is your team's work.
- Adversarial testing: Red teaming validates this design and is a separate service.
- Agent development: We do not build agents.
- Ongoing monitoring operation: We design detection. We do not run a SOC.
10 / How we do it
A traceable path from scope to evidence.
Discovery and inventory
Every agent, its tools, its reach and the reversibility of what it can do.
Permission design
Least-privilege model and blast radius per agent.
Human gates and monitoring
Gate design, baseline, indicators and alert routing.
Handover
Engineering walkthrough and a named owner.
11 / Timeline
6 to 10 weeks of work.
Elapsed time and customer effort are separated because they are not the same number.
Discovery: inventory, reach and reversibility
Every agent, its tools, its reach and the reversibility of what it can do.
Engineering access plus three to four interviews. Scope and fee confirmed at the end of this phase.
Permission design and blast radius
Least-privilege model and blast radius per agent.
Two review cycles with engineering.
Human gates and monitoring design
Gate design, baseline, indicators and alert routing.
One half-day workshop with operations.
Handover and walkthrough
Engineering walkthrough and a named owner. The fee is confirmed at the end of discovery, not before.
One 90-minute engineering session.
Our work: 6 to 10 weeks
12 / Scope check
Test whether AI Agent Security
is the right next move.
We will cover likely scope, cost and fit.
Book a confidential strategy sessionWith Steve Sharma, who would lead.13 / Who leads the engagement
Named lead. Direct assessment.

Steve Sharma
Founder & Principal
Runs discovery and authors the permission model.
Every engagement has a named lead. Where a second executive or specialist is needed, they are named in the proposal and subject to client approval.
Review leadership record14 / Why Cybersecurity Link
Three decisions.
Accountability.
Discovery pricing, stated as such.
We do not publish a number we would then revise. The fee is confirmed in writing after discovery, and discovery is itself bounded.
Blast radius over guardrails.
We design narrower reach rather than better instructions, because the second is not a control.
Human gates designed around what the person can actually check.
A gate where the human approves without understanding is worse than no gate, and we design against that.
15 / The boundary
What this engagement does not claim.
We design. We do not implement and we do not build agents.
Enforcing the boundaries in code is your team's work.
We are not a managed security service.
We design detection. We do not run monitoring.
We do not test the boundaries we designed.
Red teaming is separate and independent.
What moves the fee
With the number of agents and tools in scope. This is the primary driver, confirmed at discovery.
Where agents hold irreversible write access.
Where least-privilege permissions are already in place.
18 / How this fits
Where this sits in the wider programme.
19 / When this is not right
Sometimes the best recommendation is a smaller service, or a later date.
20 / FAQ
The questions that change the decision.
Because agent estates vary more than anything else we assess. We would rather scope it than publish a number we then revise, and discovery itself is a bounded fixed fee, so you are not signing a blank cheque to find out.
Guardrails constrain what an agent says. They do not constrain what it can reach. You cannot prompt your way to a permission boundary, and a control that depends on the model behaving is not a control.
Fewer than most organisations first propose. A gate where the person approves without understanding is worse than no gate, so we design against what the human can actually check.
No. We design the boundaries and hand over. Enforcing them in code is your team or a partner, and we will say where.
21 / Next move
If AI Agent Security is what you need, the next step is a conversation about scope.
A 45-minute conversation with Steve Sharma, who would lead the engagement: what your scope actually looks like, what it would cost, and whether this is the right service for you at all.