Your AI acted. Who authorised it?

The question isn’t whether these controls exist. It’s whether they establish one enforceable, verifiable chain of authority.

Identity and access management

May authenticate people, services and agents without preserving who acted for whom as a request passes from a person to an agent to a tool.

Model gateways

May govern requests to models without controlling the tool actions an agent takes next.

Provider logs

May document individual events at one supplier without establishing the organisation’s own complete, independent evidence chain.

Governance policies

May exist without evidence that the correct policy decision was enforced on a particular action.

Not every platform has these gaps. Some products integrate identity, policy and evidence well, and the Review starts by establishing which of your controls already work. The governance question is the authority and evidence behind each individual action, not only which models are approved for use.

Before increasing an agent’s authority, can you demonstrate the limits of its existing authority?

These are decisions a Head of Platform, CISO or CTO is asked to approve. Each is a natural point to establish the facts first:

• An AI agent is being granted access to internal systems.
• MCP tools are being connected to sensitive resources.
• A team is moving from read-only operations to actions that can change things.
• An AI application is moving into production.
• Security is investigating questionable AI activity.
• Audit or Risk is asking for evidence of individual AI decisions.
• More model providers or agent frameworks are entering the estate.

If AI use is limited to one provider’s chat product, with no tool access and little sensitive data, extending the controls you already run is often enough.

In two weeks, we assess one real AI execution path, including identity propagation, model and tool access, policy enforcement and audit evidence.

We establish what already works, identify material control gaps and give Platform, Security and Risk a defensible basis for deciding what happens next.

What you receive

1. 01

   Current-state execution and trust-boundary map

   The people, agents, models, gateways and MCP tools on the path, the routes between them, and where organisational control currently begins and ends.

2. 02

   Prioritised control-gap assessment

   What already works, and where identity propagation, model and tool access, policy enforcement and audit evidence fall short, ranked by consequence.

3. 03

   Recommended target architecture

   Where organisational control should sit and how requests would pass through it, with model providers remaining replaceable behind it.

4. 04

   First governed execution-path proposal

   The one path to bring under control first, and the reasons for choosing it.

5. 05

   Practical remediation and implementation backlog

   The work needed, in an order your teams can act on, and a proposed Accelerator scope should you want Parakletos to implement it.

The Review produces findings, a recommended architecture and a plan. It does not build or deploy a control plane; implementation is the separate, optional Accelerator. The deliverables cover the scope agreed before the Review starts, and the Review is not a comprehensive enterprise audit, a certification or a legal compliance assessment.

What you can do with them

• Brief your executive, risk or audit committee on where AI authority is, and is not, under organisational control.
• Implement the backlog with your own platform and security teams.
• Decide where a lighter approach is proportionate, so effort goes to the paths that hold the most authority.
• Scope and commission an implementation, with Parakletos or otherwise.

Implements the agreed first governed path, working with your platform and security teams. Scope, systems and integrations are agreed before work starts.

Continuing into the Accelerator is optional, and the Review’s recommendations do not depend on it. If you choose it, it starts from the Review’s backlog and proposed scope rather than a fresh discovery phase.

What the Accelerator delivers

1. 01

   Confirm the estate map and trust boundary

   Building on the Review’s current-state map and proposed boundary, agree which requests must pass through organisational control and how bypass is prevented or detected.

2. 02

   Implement the first governed path

   The agreed path, such as a coding assistant or a read-only MCP integration, routed through an organisation-controlled endpoint, including a deny path that shows a refused request was not forwarded.

3. 03

   Connect identity, policy enforcement and audit evidence

   The path connected to your identity provider, requests evaluated against versioned policy, and an evidence record written for each material action.

4. 04

   Reference architecture as built

   The path as implemented, the decisions taken and the reasoning behind them, and how further paths, providers and tools can be added.

5. 05

   Documentation and handover

   A handover to the teams who will operate and extend the path, with the documentation they need to do so.

Whether it takes six weeks or eight depends on the path chosen and on the integration work your identity, network and logging platforms require. Neither engagement certifies compliance or removes AI risk.