Guide

Agents and compliance: ISO 27001, SOC 2, and the EU AI Act

The blocker to giving agents real access is rarely security appetite — it’s compliance. “We can’t let an agent touch production, because we can’t scope it, attribute it, or revoke it.” Granular scopes and per-call audit trails answer all three, turning an ungoverned access path into a controlled, auditable surface. Here is how the controls map to the frameworks auditors actually test.

Why compliance blocks agents

The default way to wire tools into an AI app fails an audit on sight: a shared, over-privileged service account that every user’s agent inherits, no way to say which human an action belonged to, and no central log or kill-switch. An auditor sees an automated identity with broad standing access and no traceability — and writes it up. The fix is not “trust the agent more,” it’s the same access controls you already apply to people, applied to agents.

The controls auditors ask for

Four control families cover most of what ISO 27001, SOC 2 and the EU AI Act expect for automated access. Each maps to a concrete gateway property.

Least privilege & access control

OAuth scopes filter what each agent can even see or call; propagating the real user’s identity means no shared, over-privileged account exists. Access is per-user and reviewable.
Maps to: ISO 27001:2022 A.5.15 / A.8.2 / A.8.3 · SOC 2 CC6.1–CC6.3.

Accountability & audit logging

One structured, pseudonymized log line per tool call — who (hashed), what, when, which app — so every agent action is attributable and traceable after the fact.
Maps to: ISO 27001 A.8.15 / A.8.16 · SOC 2 CC7.2 · EU AI Act Art. 12 (record-keeping & traceability).

Access removal & revocation

Central OAuth revocation cuts an agent’s access across every connected app at once — no per-connector cleanup, no orphaned standing access.
Maps to: ISO 27001 A.5.18 · SOC 2 CC6.2 / CC6.3.

Human oversight

The scope grant and consent surface keep a human in control of what an agent may do, and the audit trail lets them see and stop it.
Maps to: EU AI Act Art. 14 (human oversight) · supports Art. 13 transparency.

Self-hosting is a compliance feature

Where the audit trail and any stored tokens live matters as much as that they exist. A hosted aggregator is another sub-processor holding your credentials and logs — one more entry in your SOC 2 scope and your GDPR processing records. A self-hosted gateway keeps the token vault, the audit trail, retention and pseudonymization inside your own perimeter. Fewer third parties in the access path is something auditors reward, not just tolerate.

What this is not

Do

  • +Treat scopes + audit + revocation as the technical controls behind your access-control and logging policies.
  • +Point auditors at one central, attributable log instead of N connector dashboards.
  • +Keep the token vault and audit trail in your own perimeter for data residency.

Don’t

  • −Claim a tool makes you "SOC 2 certified" or "AI Act compliant" — it provides controls, not certification.
  • −Skip your ISMS, policies, DPIA or auditor — technology is necessary, not sufficient.
  • −Treat this page as legal advice; confirm the mapping with your own auditor.

The reference implementation

Cortex Gatewayships these controls as its default behaviour: OAuth 2.1 scopes as least privilege, identity propagation so each app enforces its own permissions, one pseudonymized audit line per call, and central revocation — all self-hosted, so nothing leaves your perimeter. It’s an example of the pattern, not a certification of your programme.

Verify it

Controls you can’t evidence don’t pass an audit. Probe any domain’s access posture with the agent-readiness checker— the OAuth challenge, discovery chain and each verdict come with the curl that reproduces them, which is exactly the kind of evidence an assessor wants. See also secure MCP tooling for the security side of the same story.

FAQ

Does an MCP gateway make me SOC 2 or ISO 27001 compliant?

No — no tool certifies you. Compliance is your ISMS, policies, and an audit. What a well-built gateway does is provide the technical controls those frameworks test for on automated access: least-privilege scopes, per-user identity, a per-call audit trail, and central revocation. It closes the "agents are an ungoverned access path" finding; the certification is still yours to earn.

How does agent access relate to the EU AI Act?

If you deploy a high-risk AI system, the Act asks for automatic record-keeping and traceability (Art. 12) and effective human oversight (Art. 14). An agent that acts through scoped, per-user tokens with one audit line per action gives you the logs and attribution Art. 12 expects, and the scope/consent surface supports the oversight of Art. 14 — a human can see and stop what the agent may do. It does not by itself make a system Act-compliant, but it removes the "no traceable log of automated actions" gap.

Why is a self-hosted gateway better for compliance than a hosted one?

Because the audit trail and any stored tokens stay inside your own perimeter. A hosted aggregator is another sub-processor you must add to your SOC 2 scope and data-processing records, holding credentials and logs for you. Self-hosting keeps data residency, pseudonymization and retention under your control — auditors generally prefer one fewer third party in the access path.

How do I audit what an agent actually did?

Every tool call should write one structured log line: who (attributed to the real user, pseudonymized), what tool, when, against which app. Because access flows through one OAuth perimeter, that log is central rather than scattered across N connectors — so "show me everything this agent touched last quarter" is one query, and revoking its access is one action.
Verify any of this on a real domain with the agent-readiness checker— every result line ships the curl that reproduces it. See the pattern shipped end-to-end in cortex-gateway.