# ISO 42001 and AI agents: evidence

> ISO 42001 and AI agents meet at runtime records: who ran which tool, on which account, from which AI client, and what an access layer cannot supply.

**TL;DR** ISO 42001 asks an organization to show that its AI systems are inventoried, controlled and logged, not just that a policy exists. Elaichi is an access layer: it supplies runtime records for agent actions, including who ran which tool, on which connected account, from which AI client. Elaichi makes no ISO 42001 claim; see the Trust Center. It does not evaluate models.

## 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](https://trust.elaichi.ai). 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.

| Evidence theme | ISO/IEC 42001:2023 reference | Where it comes from |
| --- | --- | --- |
| Inventory of AI systems and the resources they reach | Clause 8.1 (operational planning and control); Annex A.4 (resources for AI systems) | The access layer |
| Access control over what an agent may do | Annex A.6, A.9 | The access layer |
| Event logging of agent actions | Clause 9.1; Annex A.6.2.8 (AI system recording of event logs) | The access layer |
| Human oversight of consequential actions | Annex A.9; clause 8.3 (AI risk treatment) | The access layer, partly |
| Model evaluation, bias testing, red-teaming | Clause 8.2; Annex A.6 | Not the access layer |
| AI impact assessment and risk treatment | Clause 8.4 (AI system impact assessment); clauses 6.1.2 to 6.1.3 | Your own management system |

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](/blog/roles-restrictions-acls-three-mechanics/) 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](/blog/which-tools-ai-agents-call/). 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](https://support.claude.com/en/articles/11176164-use-connectors-to-extend-claude-s-capabilities), 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](https://help.openai.com/en/articles/20001495-managing-app-permissions-in-chatgpt), 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](/blog/human-approval-for-ai-agent-actions/) covers where each kind of approval sits in detail.

| Capability | Minimum plan |
| --- | --- |
| Audit log, default 90-day retention | All plans, including free Personal |
| Per-call approval cards (Elaichi Agent) | Black |
| Workflow approve steps (console/Slack gate) | Black |
| Log forwarding to an external destination (Datadog) | Black |
| Custom remote MCP server as a connector | Gold |

## 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](/blog/find-mcp-servers-employees-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](https://docs.zapier.com/mcp/manage/security), 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](/blog/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](/blog/audit-log-retention-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](/blog/when-you-dont-need-an-mcp-gateway/) 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](/blog/soc2-evidence-ai-agents-cc-controls/) 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](/blog/designing-roles-for-ai-agents/). Then read [what an AI audit log must capture](/blog/what-an-ai-audit-log-must-capture/), or browse [what Elaichi connects to](/connectors/).

## FAQ

### Does Elaichi hold ISO 42001 certification?

Elaichi makes no ISO 42001 claim, and using Elaichi does not confer one on a customer. Elaichi's certifications and reports are listed in its Trust Center at https://trust.elaichi.ai. What Elaichi supplies is operational records (roles, restrictions, consent grants and an audit log of agent tool calls) that an organization can use as evidence inside its own AI management system.

### What does an audit log record when an AI agent calls a company app?

In Elaichi, each connected-tool call that reaches execution writes a row recording the acting person, the toolbox the call went through, the tool's advertised and catalog names, the connector, the connected account the call actually reached, the tool's classification (read, write or delete), whether approval was required and how it was given, the surface the call came from, the MCP client's id for calls over MCP, and whether it succeeded or failed. A call that could not be matched to one account records no connection. It records no argument values apart from the single URL path argument that names the object.

### How long are AI agent audit records kept?

Elaichi keeps 90 days of audit history in the product. An organization that needs a longer record forwards its audit events to its own log service using a logging destination, which comes with the Black plan; Datadog is the destination that delivers. A records retention schedule longer than 90 days therefore needs that forwarding set up, because the in-product history alone will not satisfy it.

### Can a human be required to approve an AI agent action before it runs?

Over an MCP endpoint, no: the person's OAuth grant is the approval, chosen once on the consent screen for that named client, and any per-call prompt the person sees comes from their AI client rather than from Elaichi. Per-call approval cards exist in the Elaichi Agent, and workflow approve steps let a named person or team approve in the console or in Slack before a step runs. Both come with the Black plan, and no AI client can answer a workflow approval request.

### Does an access layer cover model evaluation and red-teaming evidence?

No. An access layer governs and records what an AI agent does with company data through connected applications: which person ran which tool, on which account, from which client. It produces nothing about model behavior, bias testing, hallucination rates or red-team exercises. An organization that needs that evidence for ISO/IEC 42001 needs a model governance platform alongside, because the two cover different control themes.

## Read next

- [EU AI Act and AI agents: deployer duties](/blog/eu-ai-act-ai-agents/) — EU AI Act and AI agents: what the deployer duties ask of a company running tool-calling agents, and which access-layer controls produce the evidence.
- [MCP role-based access control and audit logs](/blog/mcp-role-based-access-control-and-audit-logs/) — MCP role-based access control is two decisions: a role says what a member may do, and a restriction says which tools that role can reach.
- [Which tools AI agents call: read the audit log](/blog/which-tools-ai-agents-call/) — One audit log across Claude, ChatGPT and Cursor records which tools AI agents call, naming the person, the client, the connector, the tool and the outcome.