Services

AI agents and MCP governance

An AI agent that can change business data needs an action layer with rules. I design that layer around a single MCP action server: versioned tool manifests, human approval on every write, idempotent execution, a replayable decision log and an identity that never exceeds the user’s rights.

What governed agent actions means

Reading is low risk and writing is not. If an agent calls business APIs directly, each integration decides on its own what the agent may do, how it is authorised and what gets logged, and nobody can review the behaviour in one place.

A governed action layer puts those decisions in one service. The agent proposes an action, the layer runs checks, a person approves the concrete parameters, and only then does the action execute. Every step is written to a log that can be replayed and explained afterwards.

Human-in-the-loop agent action flow Agent MCP action server Versioned tool manifests Precondition + idempotency checks Human validation on every write Action executed Append-only decision log WORM export to S3 Object Lock Identity: OAuth2 Token Exchange (Keycloak)Inherits the user’s permissions, never more
An agent can only act through one MCP action server. Every write passes checks and human validation, and every decision is logged for replay.
Text description of the diagram

An agent calls the single MCP action server, which exposes versioned tool manifests. Each action passes precondition and idempotency checks and, for every write, human validation. Only then is the action executed. An append-only decision log makes every AI decision replayable, with a WORM export to S3 Object Lock. Throughout, the agent inherits the requesting user permissions through OAuth2 Token Exchange and never exceeds them.

What gets designed

  1. One MCP action server

    All agent actions go through a single Model Context Protocol server, which holds the downstream credentials and decides whether a call may proceed.

  2. Versioned tool manifests

    Each tool declares its purpose, schemas, whether it reads or writes and which checks apply, and agents and evaluations pin to a version.

  3. Human validation and idempotency

    Every write needs approval of the exact parameters. Idempotency keys and precondition checks make a retried or stale action safe.

  4. Replayable decision log

    An append-only log of proposals, approvals, rejections and executions, exported to write-once storage such as S3 Object Lock in compliance mode.

  5. Identity

    OAuth2 Token Exchange so that the agent acts with the requesting user’s permissions and never with more.

Typical deliverables

  • MCP action-server design: versioned tool manifests, human validation on writes, idempotency
  • Identity design: permission inheritance through OAuth2 Token Exchange and workload identities
  • Decision log and audit-export design so every AI decision can be replayed
  • GDPR and AI Act by design: data residency, minimisation, erasure and transparency
  • LLM evaluation gates in CI

Who this is for

  • Teams building agents that write to business systems such as ERP, HR, ticketing or document workflows.
  • Risk, security and compliance owners who need every AI decision to be traceable and every action bounded.
  • Organisations whose first agent works in a demo and now has to be trusted with real data.

How it works

How an engagement runs

Four steps, each with something you can hold in your hands.

  1. Talk

    A 30-minute call. You describe what you are building and what is blocking it. I tell you honestly whether I can help.

  2. Map

    I review what exists and design the target: a reference architecture and decision records that your team can challenge.

  3. Build

    I work inside your team on the hard parts: the gateway, retrieval, agent actions, the pipelines. You get code, not slides.

  4. Hand over

    Evaluation gates, runbooks and dashboards, so your team can run the platform and change it without me.

Case studies

ENSO

2026 – Present

One AI platform, four products, one set of rules

Lead architect of the shared platform behind four AI product capabilities, from model access to agent actions.

  • Amazon Bedrock
  • Aurora PostgreSQL
  • pgvector
  • EKS

Guides

Common questions

What is MCP?

The Model Context Protocol (MCP) is an open protocol for exposing tools to AI models. Serving all agent actions through one MCP server gives agents a uniform interface and gives the organisation one place to add controls.

Does every agent action need human approval?

Every write does. Reads run without approval. Approval can be relaxed later for specific low-risk tools when their manifest says so; it is a deliberate choice rather than a default.

How do you make agent actions auditable?

By logging each proposal, approval, rejection and execution with the tool manifest version, the inputs and the checks that ran, in an append-only log that is exported to write-once storage.

How does an agent avoid exceeding a user’s permissions?

The platform exchanges the user’s token for a scoped token for each downstream call (OAuth2 Token Exchange), so the downstream system sees and enforces the user’s own rights.

Last updated:

Putting an agent in front of real systems?

Tell me what your agent has to do. After one call you will know whether I can help and what I would design first.

+33 6 02 73 49 22 me@osmanrami.fr