Compliance mapping
How Ferentin helps you meet ISO/IEC 42001
ISO/IEC 42001 asks your organization to run an AI management system and to prove that it operates. This page maps all 38 Annex A controls to what Ferentin contributes across LLM, MCP and agent-to-agent (A2A) traffic: the records it produces, the controls it enforces and the parts no platform can do for you.
Standard: ISO/IEC 42001:2023. Control titles are abbreviated and descriptions are our paraphrase. Refer to the standard for the normative text.
How to read this page
This is a map of how a platform supports your management system. It is not a statement about Ferentin's own certification. Ferentin holds a SOC 2 Type II report and does not hold ISO/IEC 42001 certification. Each control carries one of three labels.
- Direct evidence (9 controls). Ferentin operates the control on your AI traffic and produces records an auditor can sample.
- Supporting (18 controls). The control is your process. Ferentin enforces part of it or supplies the data it runs on.
- Your management system (11 controls). Organizational work that no gateway can do. We say so rather than stretch a feature to fit.
A mapping that claims every control is the mapping an auditor stops reading. The grey rows are there so you can trust the green ones.
All 38 Annex A controls
Grouped by control family. Each family links to its section below.
| Control | What it asks | Ferentin contribution | Label |
|---|---|---|---|
| A.2 Policies related to AI | |||
| A.2.2 AI policy | A documented AI policy, approved by top management. | Turns the policy's enforceable clauses (models, tools, data, approvals) into policy evaluated on every request. | Supporting |
| A.2.3 Alignment with other organizational policies | The AI policy is consistent with security, privacy and other policies. | The same SSO, RBAC and data-protection rules that govern the rest of your estate apply to AI traffic. | Supporting |
| A.2.4 Review of the AI policy | The AI policy is reviewed at planned intervals. | Usage, enforcement and block reporting give the review real operating data. | Supporting |
| A.3 Internal organization | |||
| A.3.2 AI roles and responsibilities | Roles and responsibilities for AI are defined and allocated. | RBAC roles synced from your IdP through SCIM, named approvers for high-risk actions, and an owner recorded for each AI system in the inventory. | Supporting |
| A.3.3 Reporting of concerns | People can report concerns about AI systems. | Not provided. Ferentin does not run an AI concern-reporting channel for your staff. | Your management system |
| A.4 Resources for AI systems | |||
| A.4.2 Resource documentation | The resources each AI system relies on are identified and documented. | AI Systems Inventory: every AI client, LLM provider and MCP server, with owner, purpose, risk tier and deployment status, plus AI tools discovered on enrolled devices. | Direct evidence |
| A.4.3 Data resources | The data used by AI systems is documented. | Data-protection detections show which categories of sensitive data reach which systems. | Supporting |
| A.4.4 Tooling resources | The tools AI systems use are documented. | MCP and A2A registries: every server, tool, agent and skill, with description and the teams allowed to use it. | Direct evidence |
| A.4.5 System and computing resources | The computing resources AI systems consume are documented. | Tokens, cost and latency recorded per provider, model, user and team. | Direct evidence |
| A.4.6 Human resources | The people and competencies AI systems need are documented. | Not addressed by the platform. | Your management system |
| A.5 Assessing impacts of AI systems | |||
| A.5.2 AI system impact assessment process | A process for assessing the potential consequences of AI systems. | Not provided. | Your management system |
| A.5.3 Documentation of impact assessments | Impact assessment results are documented and retained. | Not provided. | Your management system |
| A.5.4 Assessing impact on individuals or groups | Impacts on individuals and groups are assessed. | Supplies inputs: who uses each system, what data categories flow through it, what actions agents take. | Supporting |
| A.5.5 Assessing societal impacts | Impacts on society are assessed. | Not addressed by the platform. | Your management system |
| A.6 AI system life cycle | |||
| A.6.1.2 Objectives for responsible development | Objectives guide responsible AI system development. | Not addressed by the platform. | Your management system |
| A.6.1.3 Processes for responsible design and development | Defined processes for responsible design and development. | Not addressed by the platform. | Your management system |
| A.6.2.2 AI system requirements and specification | Requirements for AI systems are specified. | Requirements on which models, tools and data a system may use are expressed as versioned, enforced policy. | Supporting |
| A.6.2.3 Documentation of design and development | AI system design and development is documented. | Not addressed by the platform. | Your management system |
| A.6.2.4 Verification and validation | AI systems are verified and validated before use. | Policies can run in simulation mode before enforcement. Model output quality is not evaluated. | Supporting |
| A.6.2.5 AI system deployment | Deployment is planned and controlled. | Deny-by-default: nothing is reachable until an admin adds it. A2A skills are reviewed before they are served. Changes audited. Signed policy bundles verified at the edge. | Direct evidence |
| A.6.2.6 AI system operation and monitoring | AI systems are monitored in operation. | Real-time dashboards for usage, enforcement and blocked requests, data-protection and prompt-injection detections, a daily re-check of public A2A agent cards, and device-level findings from the endpoint agent. | Direct evidence |
| A.6.2.7 AI system technical documentation | Technical documentation is available to the parties who need it. | Model catalog records capabilities, modalities, limits and provider data policy. Tool schemas are registered. | Supporting |
| A.6.2.8 Recording of event logs | Event logs are recorded for AI systems. | Every LLM and MCP call logged with identity, decision and trace context, each with an offline-verifiable Ed25519 receipt. Every A2A call logged with agent, skill and acting user. | Direct evidence |
| A.7 Data for AI systems | |||
| A.7.2 Data management process | Data used by AI systems is managed through a defined process. | Data-loss prevention on LLM, MCP and A2A traffic and, on enrolled devices, inside AI coding tools. Redaction, per-tenant retention and Zero Data Retention enforce the process at runtime. | Supporting |
| A.7.3 Acquisition of data | How data is acquired for AI systems is controlled. | Data reaches agents only through registered MCP servers, tools and A2A agents that a user's role allows. | Supporting |
| A.7.4 Quality of data for AI systems | Data quality requirements are defined and met. | Not addressed by the platform. | Your management system |
| A.7.5 Data provenance | The origin of data is recorded. | Tool results carry provenance markers. The audit trail records the server and tool that supplied them. | Supporting |
| A.7.6 Data preparation | Data preparation methods are defined. | Sensitive values can be redacted, and untrusted content sanitized, before it reaches a model. | Supporting |
| A.8 Information for interested parties | |||
| A.8.2 System documentation and information for users | Users get the information they need about AI systems. | Tool Discovery: approved tools, with descriptions, in a self-service catalog. | Supporting |
| A.8.3 External reporting | Interested parties can report adverse impacts. | Not provided. | Your management system |
| A.8.4 Communication of incidents | AI incidents are communicated to the people affected. | The audit trail reconstructs who used what, when and with which decision, so you can scope an incident before you communicate it. | Supporting |
| A.8.5 Information for interested parties | Obligations to report information about AI systems are met. | Compliance report and audit log exports. | Supporting |
| A.9 Use of AI systems | |||
| A.9.2 Processes for responsible use | Processes for the responsible use of AI systems are defined. | Policy evaluated on every request, including A2A, with human-in-the-loop approval gates for high-risk agent actions. | Direct evidence |
| A.9.3 Objectives for responsible use | Objectives guide responsible use. | Enforcement and approval metrics measure progress against the objectives you set. | Supporting |
| A.9.4 Intended use | AI systems are used as intended. | Per-role allowlists bind each system to its approved users, tools and data. Everything else is denied by default and recorded. On enrolled devices, unapproved local MCP servers can be quarantined or blocked. | Direct evidence |
| A.10 Third-party and customer relationships | |||
| A.10.2 Allocating responsibilities | Responsibilities between you and third parties are allocated. | This page states what Ferentin covers and what stays yours. The sub-processor list is published. | Supporting |
| A.10.3 Suppliers | Suppliers' services align with your responsible approach. | Per-tenant provider allowlist, per-model provider data policy, MCP catalog scanning with enforced verdicts, and A2A agent card signature checks. | Direct evidence |
| A.10.4 Customers | Your customers' expectations are reflected in how you provide AI. | Not addressed by the platform. | Your management system |
A.2
Policies related to AI
Ferentin cannot write your AI policy, and nothing on this page should suggest otherwise. What it changes is the status of the policy's enforceable clauses. Which models staff may use, which tools agents may call, which data may leave the organization and who must approve a high-risk action stop being statements of intent. They become policy that the Service Edge evaluates on every request.
That makes the review your AI policy needs (A.2.4) a review of what actually happened, not of what was intended. Usage, enforcement decisions and blocked requests come straight out of the audit trail.
Evidence you can hand an auditor
- • Policy definitions in the Policy Editor, with every change recorded against the admin who made it
- • Per-request policy decisions in the audit trail: which policy matched, for which identity
- • Usage and enforcement reports exported for the management review
What stays yours
Writing, approving, communicating and reviewing the AI policy, and deciding how it aligns with your information security, privacy and procurement policies.
A.3
Internal organization
ISO/IEC 42001 asks who is accountable for each AI system and who decides when something is risky. Ferentin cannot assign those responsibilities. It can make them operational. Roles come from your identity provider. Approval gates route high-risk agent actions to named approvers. Every approval or denial is recorded against the person who made it.
Evidence you can hand an auditor
- • Role assignments sourced from your enterprise IdP (Okta, Entra ID, Google Workspace, Ping Identity)
- • Approval records showing which named approver decided, what they decided and when
- • Owner recorded per AI system in the AI Systems Inventory
What stays yours
Defining AI roles, documenting who holds them, and running a channel through which staff can raise concerns about AI.
A.4
Resources for AI systems
An auditor's first question is usually some form of "show me your AI systems." Ferentin answers it from traffic, not from a spreadsheet someone last updated in spring. Every AI client, LLM provider and MCP server flowing through the Service Edge is cataloged in the AI Systems Inventory with owner, purpose, risk tier and deployment status.
Compute and tooling come from the same source. Token usage, cost and latency are recorded per provider, model, user and team. Every MCP server and tool is registered with its description and input schema. Third-party A2A agents are registered from their agent card, and each of their skills is listed and reviewed like a tool.
The gateway only sees what is routed through it. On enrolled devices, the Ferentin endpoint agent fills in the rest: AI apps and agents installed on the device, MCP servers configured locally in AI clients and repositories, AI coding tools, and the network destinations AI tools reach. Those findings land in the same Shadow AI Inventory.
Evidence you can hand an auditor
- • AI Systems Inventory export
- • Shadow AI Inventory from enrolled devices: installed AI tools, local MCP servers, repository MCP configs and AI destinations
- • LLM and MCP registries, including tool descriptions and schemas
- • A2A agent registry: each agent's card, its skills and each skill's review decision
- • Usage and cost reports broken down by provider, model, user and team
What stays yours
Documenting the people and competencies behind each AI system, and any AI resources outside Ferentin.
A.5
Assessing impacts of AI systems
Impact assessment is the widest part of ISO/IEC 42001 and the part a gateway can contribute least to. It asks how an AI system could affect individuals, groups and society, and that is a judgment, not a log line. Ferentin does not perform impact assessments and does not claim to.
It does supply the inputs that make an assessment factual rather than speculative: which systems exist, which groups (from your IdP) use them, what categories of sensitive data flow through them, what actions agents take on people's behalf, and what was blocked.
Evidence you can hand an auditor
- • Inventory and usage data, by group, for the systems under assessment
- • Data-protection detection history showing what sensitive data categories actually flowed
- • Agent action history from the MCP audit trail
What stays yours
The impact assessment process, the assessments themselves and their documentation. Societal impact in particular has no platform-side evidence.
A.6
AI system life cycle
Most Ferentin customers deploy third-party models and tools rather than train their own, so this section reads A.6 from the deployer's side. If you develop models, the development-side controls (A.6.1.2, A.6.1.3, A.6.2.3) stay entirely with your engineering process.
Deployment is where Ferentin is strongest. An LLM provider, model or MCP server is unreachable until an admin adds it, so deployment is an explicit, recorded act rather than something that happens when a developer pastes an API key. Configuration changes are audited with the actor. Policy bundles are signed with DSSE / ECDSA-P256 at the control plane and verified at the edge before they apply.
For event logs (A.6.2.8), every LLM and MCP call is recorded with actor identity, token reference, policy decision and OpenTelemetry trace context. Each event carries an Ed25519-signed receipt that an auditor can verify offline with a standalone CLI, so the evidence does not depend on trusting the system that produced it. Zero Data Retention, available on every plan, stops payload storage. Audit events are still kept, so you can drop payloads without losing the log.
A2A agents get the same deployment discipline. An agent is registered from its card, its skills are reviewed before they are served, and public cards are re-checked daily. A card whose signature no longer verifies against the keys you pinned, or that moves the agent to a new endpoint, blocks the agent until an admin confirms. A skill whose description changes keeps serving the approved text until someone re-reviews it. Every A2A call is recorded with the agent, skill, protocol version, data-protection decisions and the acting user.
Evidence you can hand an auditor
- • Admin audit trail of provider, model and MCP server additions, changes and removals
- • Signed policy bundle history
- • Per-call LLM and MCP audit events with signed receipts, plus the verification CLI
- • A2A activity: one record per agent call, with skill, protocol version, outcome and data-protection decisions
- • Policy simulation results recorded before enforcement
What stays yours
Development-side objectives, processes and design documentation, and validating that a model is accurate, fair and fit for your use case.
Honest gap
Ferentin does not evaluate model output quality: accuracy, bias or hallucination rates. Validating a model for your use case remains part of your verification and impact assessment work.
A.7
Data for AI systems
A.7 is written mainly for organizations that train models, and its quality and preparation controls are about training data. For a deployer, the live question is what data reaches a model at inference time, and that is a question Ferentin answers on every request.
Data-loss prevention (cards, IBAN, SSN, exfiltration URLs) runs on LLM input and output and on MCP tool traffic, in the cloud and at the edge, and on A2A messages in both directions. An A2A file Ferentin cannot scan is refused unless your policy explicitly allows it. Sensitive values can be redacted before they reach a model. Tool results are spotlighted and datamarked with provenance markers, and the audit trail records which server and tool supplied each piece of data. A private Service Edge running inside your own VPC keeps the traffic inside your network.
Evidence you can hand an auditor
- • Data-protection detection and redaction events
- • Per-tenant payload retention configuration, including Zero Data Retention elections
- • Tool-call audit records naming the source server and tool
What stays yours
Data quality, and every A.7 control as it applies to data you use to train or fine-tune models.
A.8
Information for interested parties
Users need to know which AI tools they may use and what those tools do. Auditors and regulators need evidence. After an incident, you need to know exactly what happened before you can tell anyone about it.
Ferentin covers the first need with Tool Discovery, a self-service catalog of approved tools with their descriptions. It covers the second with compliance report exports. It covers the third with the audit trail: a signed record of who called which model or tool, with which decision, that lets you scope an incident before you communicate it.
Evidence you can hand an auditor
- • Tool Discovery catalog contents
- • Compliance report and audit log exports
- • Incident timelines reconstructed from signed audit events
What stays yours
An external channel for reporting adverse impacts, and the decision about what to communicate to whom after an incident.
A.9
Use of AI systems
A.9 is where a gateway does the most work, because responsible use is exactly what the Service Edge enforces. The Policy Engine sets rules by user, team, model, tool, time and data sensitivity. It evaluates every request before execution, not once at session start. Approval gates send high-risk agent actions to designated reviewers with full context before they proceed.
Intended use (A.9.4) becomes something you can prove rather than declare. Each AI system is bound to the users, tools and data it was approved for, and everything else is denied by default. The audit trail shows the boundary held and records each refusal.
The same chain governs agent-to-agent traffic in both directions. When your users or agents call a third-party A2A agent, each skill is a governed tool. When an outside A2A client calls an agent you have installed, through your tenant's A2A gateway, its request passes the same per-user skill permissions, constraints, step-up and approval gates before anything is sent. Each caller sees only the tasks it started.
On enrolled devices, the endpoint agent carries the boundary onto the device. A locally configured MCP server that has not been approved can be quarantined or blocked in the client's own config, with a request-approval path for the developer. Call-time rules can deny individual tool calls in supported AI coding tools.
Evidence you can hand an auditor
- • Policy definitions, change history and simulation results
- • Per-request allow and deny decisions with the matching policy
- • Approval records for gated agent actions, including messages sent to A2A agents
- • Endpoint rule decisions: local MCP servers quarantined or blocked, approval requests and their outcomes
What stays yours
Setting responsible-use objectives and deciding what each AI system's intended use is. Ferentin enforces the boundary you draw.
A.10
Third-party and customer relationships
Almost every organization's AI estate is mostly third parties: model providers, MCP servers, AI clients. A.10.3 asks you to make sure those suppliers fit your responsible approach. Ferentin makes that a gate. An LLM provider or MCP server that is not on the tenant allowlist is unreachable.
The model catalog records each model's provider data policy: whether the provider trains on user data, whether it retains prompts and for how long, plus links to its terms and privacy policy. The console shows that information while an admin chooses models. Third-party MCP servers are scanned for catalog poisoning at import, and an admin's block verdict is enforced at call time as well as hidden from listings. Third-party A2A agents can be pinned to their publisher's signing keys: a card that stops verifying blocks the agent. Every agent card and endpoint URL is checked against internal-network targets before Ferentin connects.
Ferentin is also one of your suppliers. Our SOC 2 Type II report, sub-processor list and this page are the inputs for assessing us.
Evidence you can hand an auditor
- • Tenant provider allowlist and its change history
- • Model catalog data-policy fields for every model in use
- • MCP catalog scan verdicts and admin override decisions, with reasoning
- • A2A agent card revisions, signature status and blocks
- • Ferentin SOC 2 Type II report and sub-processor list
What stays yours
Supplier contracts and due diligence, and how you meet your own customers' expectations when you offer AI to them.
Agent-to-agent
A2A agents are inside the same controls
An AI system increasingly includes other organizations' agents. Ferentin governs A2A traffic (protocol versions 0.3 and 1.0) in both directions through the same policy, data-protection and audit chain as LLM and MCP traffic, so it counts toward the controls above rather than sitting outside them.
Your agents calling third-party A2A agents
An admin registers an A2A agent from its agent card and installs it. Each skill becomes a governed tool, so the agent is reached only by the users and agents your policy allows, with data-loss prevention on what is sent and what comes back, and every call recorded.
Outside A2A clients calling your agents
Your tenant's A2A gateway lets an external A2A client reach an agent you have installed. Every request carries a token issued to that caller, passes the same skill permissions, constraints, step-up and approval gates, and is scanned in both directions. Each caller sees only the tasks it started, and calls are recorded in the A2A audit trail.
Endpoint
macOS · Linux pilotThe AI your gateway never sees
A local MCP server is a subprocess talking over pipes. It never opens a socket, so no proxy, secure web gateway or DNS filter has ever seen one. The same goes for an AI coding CLI using its own credentials. An inventory built only from gateway traffic misses them, and an auditor asking for your AI systems (A.4.2) or your intended-use boundary (A.9.4) will find them. The Ferentin endpoint agent runs on enrolled devices and reports them into the same inventory and policy. It is available for macOS today, Linux is in pilot, and Windows support is coming.
What it discovers
- • Installed AI apps and software agents, matched against a detection catalog Ferentin maintains and pushes to devices
- • MCP servers configured locally, local (stdio) and remote, in the major AI clients and in repository config files
- • AI coding tools: Claude Code, Cursor, Codex and GitHub Copilot CLI, through managed hooks
- • Skills, plugins, extensions and hook configurations installed for AI tools
- • Network destinations reached by AI tools, attributed to the app that opened the connection
What it governs
- • Rules for locally configured MCP servers: report, quarantine or block an unapproved server, with an approval request for the developer
- • Call-time rules in supported AI coding tools that deny an individual tool call (tenant opt-in)
- • Data-loss prevention inside supported AI coding tools, on prompts, tool inputs and tool outputs
- • Block rules for AI network destinations
- • Signed device policy bundles, verified on the device before they apply
Clauses 4–10
Where Ferentin evidence feeds the management system
The clauses are the management system itself, and running them is your work. The same operating records that evidence the Annex A controls above also feed five of them.
| Clause | What Ferentin supplies |
|---|---|
| 6.1.2 AI risk assessment | The inventory and usage data give the risk register real systems and real traffic to assess. |
| 8.1 Operational planning and control | Policy enforcement at the Service Edge is the operational control, applied to every request. |
| 9.1 Monitoring, measurement, analysis and evaluation | Usage, enforcement, approval and detection metrics measure your AI objectives against real operation. |
| 9.2 Internal audit | Auditors sample exported events and verify their signed receipts offline, independently of Ferentin. |
| 10.2 Nonconformity and corrective action | The audit trail reconstructs what happened, which is the starting point for a corrective action. |
FAQ
ISO/IEC 42001 and Ferentin
No. Ferentin holds a SOC 2 Type II report. This page is not a certification claim. It maps how the Ferentin platform helps your organization operate the AI management system that ISO/IEC 42001 certifies.
Related reading
Other frameworks, mapped the same way.
Posture
OWASP Agentic Top 10 Coverage
Per-risk control mapping against the OWASP Top 10 for Agentic Applications 2026.
Guide
Zero Trust alignment
Ferentin against Zero Trust maturity tiers, with known gaps disclosed.
Supplier assessment
Sub-processors
The third parties Ferentin uses, for your A.10.3 supplier assessment of us.
Trust Center
SOC 2 report and compliance evidence
Audit reports, security questionnaire responses and gated compliance documentation.
Preparing for certification
See the evidence from your own traffic
Book time with our team to walk through the inventory, audit trail and exports an auditor would sample, in your stack, with your policies.