ISO 42001 and AI agents: evidence

ISO 42001 and AI agents: the evidence gap at runtime

Your ISO 42001 work probably started with documents: a policy, a risk assessment, an impact assessment, a statement of applicability. Then someone connected Claude to Salesforce, and the auditor's question changed shape. It stopped being "what does your policy say" and became "show me what the agent did last Tuesday." ISO 42001 and AI agents meet at runtime records, not at documents.

That gap splits into two separate problems, and most published guidance answers only one. Model governance covers evaluation, bias testing, red-teaming, and model documentation. This maps to ISO/IEC 42001:2023 clause 8.2 (AI risk assessment) and Annex A.6 (AI system life cycle). Access governance covers which person's agent reached which company app, with whose credentials, and what it changed. This maps to Annex A.9 (use of AI systems) and clause 9.1 (monitoring, measurement, analysis, evaluation). An access layer answers the second and produces records for it. It does not touch the first. This post is about what an access layer can and cannot supply. It is stated once here, so it is not re-argued section by section below.

Elaichi is a governed MCP control plane. MCP (Model Context Protocol) is the standard an AI client uses to call tools. Elaichi serves it at one address that Claude, ChatGPT, Cursor and Microsoft Copilot all sign into. Every call made through it is checked against the caller's access and written to an audit log.

Settle one thing before anything else: Elaichi makes no ISO 42001 claim, and nothing in this post confers a certification on you. This is a description of Elaichi's own product behavior, not independent compliance guidance. Treat it as "according to Elaichi's documentation," not as a general reference on the standard. Elaichi's certifications and reports are listed in the Trust Center. This maps to ISO/IEC 42001:2023, the current edition of the standard; clause and Annex A numbers below refer to that edition.

Which control themes an access layer can supply records for

Three terms get used loosely in this space, so fix them first. A connector is an integration definition in the catalog (Salesforce, Datadog, GitLab). A connection is one authenticated account under a connector. "Acme's Salesforce production org" is a connection, not a connector. A toolbox is a named list of tool entries, each pinned to exactly one connection. A grant assigns it to a person or a client at consent. An audit row normally names all three, because a connector alone does not tell you which account was reached. A call that could not be matched to one account records no connection.

Here is the division of labor, with the clauses each theme is usually evaluated against. Treat the ISO column as a starting map, not a certified crosswalk. Your certification body's auditor finalizes the control-to-evidence mapping during stage 1.

An access layer is not the only way to produce the top four rows. A self-hosted MCP reverse proxy can produce comparable per-call logs. You build the role model, the restriction engine and the log schema yourself. The choice is between tool-level semantics out of the box and a logging layer you assemble and maintain.

For the themes a governed MCP layer does cover, here are the concrete mechanisms in Elaichi.

Access control. A member holds exactly one role in an organization, and each role bundles permissions from Elaichi's permission catalog. Restrictions sit on top: an allow or block rule aimed at a role or at one member, naming whole connectors or single tools. There is no organization-wide restriction and no team restriction. A rule covering a team is written on their role, or on each member. A block always beats an allow within a layer. The split between a role and a restriction is one to get right before you write either. Restrictions are enforced at every point a member can reach a tool. That includes when tools are advertised to a client, and when a call executes.

Event logging. Every connected-tool call that reaches execution writes an audit row. The row records the acting person, the toolbox, and the tool's advertised and catalog names. It also records the connector, the connection the call actually reached, and the tool's classification. Last come how approval was given, the surface the call came from, the MCP client's id when it came over MCP, and the outcome.

Human oversight. This needs a caveat that matters for an audit. Over MCP there is no per-call approval. The person's OAuth grant is the approval. They chose the scopes on Elaichi's own consent screen for that named client. Elaichi then runs every call that passes the scope check as already approved. A per-call confirmation the person sees inside Claude or ChatGPT is that client's own prompt. It is not Elaichi's, and not a control Elaichi can log or enforce.

Those client prompts are real controls, set by the client vendor. Anthropic documents three settings for Claude connector tool permissions: Always allow, Needs approval or Blocked (support.claude.com, checked October 2026). Each applies to a whole connector, a category of its tools, or a single tool. OpenAI says Always allow is not offered as a persistent permission to members of a managed ChatGPT workspace (help.openai.com, checked October 2026). Both live in the client's own settings, and neither writes to Elaichi's audit log.

Two features change that. The Elaichi Agent shows a per-call approval card. A workflow approve step asks a named person or team to approve first, in the console or in Slack. No AI client can answer that request on their behalf. If your risk treatment depends on a human in the loop before a specific action, build it into one of these two. Do not build it into an MCP client's prompt. Human approval for AI agent actions covers where each kind of approval sits in detail.

How an inventory of AI agents works through one endpoint

An inventory of AI systems is hard when every employee configures their own tools. One organization-wide endpoint makes the inventory a query rather than a survey.

Elaichi serves MCP at one address, https://api.elaichi.ai/mcp, the same string for every organization. Which organization, which person and which tools a client reaches comes from the OAuth grant behind the token, not from the URL. OAuth is the sign-in handshake: the person approves, in a browser, what a named client may do.

That shape gives three inventory facts an auditor can read directly, without a survey of employee machines.

Which clients are connected, and by whom. Every approval creates its own grant. Each person lists and disconnects their own under Settings, then Connected apps. The list shows the app name, the access granted, the toolboxes it reaches, when it was connected and when it was last used. Elaichi writes an audit entry when a grant is created at consent, and when the first token exchange activates it. It writes one again when its toolboxes change, and when it is disconnected.

Which client it actually is. A client's name is shown as verified only when every non-loopback redirect address it registered maps to the same known client. Exactly seven can be verified: Claude, ChatGPT, Cursor, Grok, Perplexity, Mistral and Devin. Anything else shows the name the client registered for itself, flagged "Name provided by the client itself." State that plainly in your evidence pack. A name on a consent screen is a claim, not a proof, and Elaichi labels which is which.

Which resources each one reaches. A grant either reaches everything the person can run, re-resolved on every call, or exactly the toolboxes they picked at consent.

The shape has a limit, and it belongs in your scope statement. Elaichi governs calls that pass through it. A client configured to reach a vendor's MCP server directly, outside Elaichi, is outside this inventory. There is no record of it anywhere in Elaichi's logs. Finding those connections is a separate exercise. The MCP servers employees have installed covers how far client admin consoles get you. In most cases that is not very far.

One audit shape across Elaichi connectors and vendor MCP servers

Elaichi's catalog holds two kinds of connector, and both produce the same audit row shape. That matters: otherwise an evidence pack means reconciling two log formats by hand.

Most connectors in the catalog are ones Elaichi authors and runs itself. The rest are native MCP connectors: a vendor builds and runs its own MCP server, and Elaichi staff publish it once for every organization. Datadog, Linear, GitLab, PostHog, Miro and Zapier are among them. Zapier MCP is Zapier's own product, and its unit is the server rather than the address. Each user creates and owns their own servers on the Zapier account, and the endpoint URL is shared (docs.zapier.com, checked November 2026). For a native MCP connector, the vendor owns the tools. Elaichi handles sign-in, access and audit in front of them. An organization on Gold can also register its own remote MCP server as a connector, bringing a self-run server under the same rules. Vendor MCP servers through Elaichi goes into the mechanics.

Whatever the kind, the same things hold. Tools come through the same address and the same search-and-run tools. Restrictions and OAuth scopes are checked before the call leaves Elaichi. Only a tool on that connection's active list can run. Every call that reaches execution is written to the audit log, with the person, the connector, the connection and the MCP client.

Two retention facts belong in your records policy, not in a footnote. Elaichi keeps 90 days of audit history in-product. For longer, forward it to your own log service; Datadog is the supported destination, gated to Black (see plan table above). If your records schedule says seven years, 90 days of in-product history is not it. Audit log retention for AI actions walks through the gap.

The other fact is about what the log does not hold. A tool-call row records no argument values, with one exception. The value of the single URL path argument that names the object is kept as the target id. It records neither argument names nor an argument count. If your evidence needs to show exactly what text an agent sent into a connected app, Elaichi's audit log will not supply it. Closing that gap needs a different control, such as DLP on the destination app, or your own request logging.

Where an access layer stops, and what certification it does not confer

An access layer produces operational records for your AI management system. It does not certify you. Nothing here changes the certification process: stage 1 and stage 2 audits, surveillance audits, and a three-year cycle under an accredited body.

Be specific about the boundary in your statement of applicability. Elaichi does not evaluate models, score hallucination rates, run red-team exercises, or produce model documentation (clause 8.2, Annex A.6 territory). If those are the controls under review, a model governance platform is the right purchase and an access layer is beside the point. If what is under review is what an employee's assistant did inside Salesforce, Snowflake or Zendesk, the access layer is where the records live. That is clause 9.1, Annex A.6.2.8 and A.9 territory. Elaichi's certifications and reports are listed in its Trust Center at https://trust.elaichi.ai.

There is also a case where none of this is needed yet: one person, three connected apps, nobody else touching them. The governance problem is small enough that the free Personal plan's own audit log answers it, and a control plane is overhead. The same goes for a team whose models and data never touch a third-party app. When you don't need an MCP gateway yet makes that case directly.

Finally, the detail that breaks evidence packs more than any missing feature: role, team and restriction changes need about two minutes to reach every surface. If your procedure says "revoke and re-test," build the pause in. Grant revocation, member removal and suspension are different. Those stop a client on its next call, and so do revoking a share and disconnecting an account.

For adjacent frameworks, SOC 2 evidence for AI agents maps the same records to CC6 and CC7. The EU AI Act's deployer obligations sit alongside both. To scope roles before any of this, start at designing roles for AI agents. Then read what an AI audit log must capture, or browse what Elaichi connects to.