3366 Members
Join Permit's SlackEurope published its first harmonised standard under the EU AI Act. EN 18286:2026, titled "Artificial intelligence: Quality management system for EU AI Act regulatory purposes," operationalises Article 17's QMS requirements for providers of high-risk AI systems as auditable processes.
The standard was approved by CEN on 12 July 2026 and its reference was published in the Official Journal via Commission Implementing Decision (EU) 2026/2274 around World Standards Day on October 14. The Commission announced it on October 19.
If you follow EN 18286 for the Article 17 requirements it covers, you get a presumption of conformity. That is what "harmonised standard" means in EU regulation: compliance with the standard is accepted as evidence of compliance with the corresponding legal requirements.
The standard does not replace existing management systems. CEN-CENELEC explains that EN 18286 is built to sit on top of ISO/IEC 42001, ISO 9001, or a sector QMS. It addresses risk management, human oversight, data quality, and cybersecurity as auditable processes.
EN 18286 does not mention AI agents, authorization, or MCP. It is a process standard for high-risk AI systems. But teams shipping AI agents should pay attention, because the QMS requirements it operationalises are exactly the processes that agent authorization systems produce evidence for.
The standard translates Article 17 of the AI Act into clauses that auditors can check. The clauses include:
The CEN-CENELEC announcement confirms the standard addresses risk management, human oversight, data quality, and cybersecurity.
For AI agents that can take actions (call tools, mutate data, send messages, access resources), these requirements translate to operational questions:
These are authorization problems. A QMS for an agentic system needs evidence of what was allowed and why.
Many agent systems inherit user permissions directly. The agent authenticates as the user, assumes their OAuth token, and operates with every privilege that user holds. This is the status quo for most agentic AI integrations.
The problem: that pattern produces weak evidence for a QMS. When an agent inherits user permissions, you cannot easily show:
For more on why this pattern is an anti-pattern, see Do AI Agents Inherit User Permissions? and Agents as Privileged Identities.
A QMS built for EN 18286 will need documented information about how the AI system operates. If your agents run with inherited user tokens and no additional authorization layer, the documented information is thin: "the agent can do whatever the user can do." That is hard to audit and harder to scope.
Per-action authorization gives the agent its own identity, separate from the user it acts for. Every tool call runs through a policy check. Sensitive actions require human approval before execution. Decisions are logged with enough context to reconstruct what happened.
This pattern produces evidence that maps directly to EN 18286's areas of concern:
Risk management: Each tool call is a risk boundary. A policy engine evaluates context (who is the user, what is the resource, what is the sensitivity, what time is it, what has this agent done recently) before allowing the action. You can define risk thresholds in policy and prove they were evaluated.
Human oversight: Approval workflows block sensitive actions until a human confirms. The approval record links to the action, the approver, and the timestamp. For more on structuring these workflows, see Human-Agent Delegation Audit Trail.
Data quality: Per-action policies can restrict what data an agent accesses based on classification, tenant, or sensitivity labels. Restricting access to appropriate data is easier when the policy evaluates every request.
Documented information: Every authorization decision writes a log entry. The log captures agent identity, user principal, resource, action, policy version, decision, approval state, and outcome. For the full schema, see AI Agent Audit Logs: The 12 Fields Auditors Expect.
A QMS backed by per-action authorization evidence is more auditable than one that documents "the agent uses the user's OAuth token."
If you build or operate AI agents that may be classified as high-risk or that serve enterprise customers who care about compliance posture, here is a starting point:
Separate agent identity from user identity. The agent should authenticate as itself, with its own credentials, even when acting on behalf of a user. This makes delegation explicit.
Route tool calls through a policy decision point. Before the agent executes a tool, evaluate a policy that considers the user, agent, resource, action, and context. This is where risk thresholds live.
Implement human-in-the-loop for sensitive actions. Some actions should not proceed without human approval. Build approval workflows that block execution until a human confirms, and record the approval with the decision.
Log authorization decisions, not just tool outputs. Capture who or what acted, for whom, on which resource, under which policy, with what result. Store the policy version so you can prove which rules applied.
Define scope in policy, not just in prompts. Prompts are not enforcement. A policy engine is enforcement. If you need to prove an agent was restricted to certain resources or actions, the proof comes from policy evaluation, not from instructions the agent may or may not follow.
Connect logs to incident response. The point of documented information is reconstruction. If an incident occurs, you should be able to answer "what did the agent do, on whose authority, and why was it allowed?" without reverse-engineering from scattered API logs.
Review delegation chains. If agent A invokes agent B, or if a workflow orchestrates multiple agents, the authorization chain should be traceable. Each link in the chain should have its own policy evaluation and log entry.
Permit.io provides the authorization layer that produces this evidence. The architecture includes:
The MCP Gateway sits between agents and tools. Every tool call runs through policy evaluation before the tool executes. This is where you enforce human oversight, log the decision, and produce documented information.
For teams preparing for EU AI Act compliance or responding to enterprise customer security questionnaires, this architecture turns "how do you control your agents?" from a hand-wave into a policy configuration and a log trail.
EN 18286 does not prescribe Permit or any vendor. It operationalises Article 17 as auditable processes. Per-action authorization with a policy engine, approval workflows, and decision logs is one way to implement those processes with evidence auditors can check.
No. EN 18286 operationalises Article 17, which applies to providers of high-risk AI systems. Not all AI agents are high-risk. But the same design pattern (per-action authorization with logged decisions and approval workflows) helps whether you are high-risk or responding to enterprise customer requirements.
EN 18286 covers the Article 17 QMS requirements and gives a presumption of conformity for those requirements. The AI Act has other requirements beyond Article 17. Compliance depends on your full posture, not just one standard.
No. EN 18286 is a process standard for quality management systems. It addresses risk management, human oversight, data quality, and cybersecurity as auditable processes. Authorization systems are one way to implement those processes with evidence.
The standard is published by CEN. The Official Journal reference is available through EUR-Lex. For background, see the Commission announcement and the CEN-CENELEC publication notice.
Ready to build agent authorization that produces audit evidence? Talk to our team or start with a free account.
Co-Founder & VP of R&D at Permit.io
