Skip to content
AIAC AI ASSURANCE COUNCIL™

Agentic AI oversight

Model AI Governance Framework for Agentic AI v1.5, §§2.1.2 and 2.3.1 — Bound risks through design by defining agents limits and permissions

Least privilege for agents is a recommendation, not a rule. The EU AI Act contains no least-privilege provision — the phrase appears nowhere in it — and the framework that does recommend the practice says organisations should, never shall. What makes it worth following is that the alternative is a permission model expressed in a prompt.

§ 1 — Who it binds

Every agent that holds a credential

Deployer

Any agent holding a credential, calling a tool, or reaching a system through a protocol — which is every agent that does anything. The framework attaches no threshold, and the exposure scales with what the tool can do rather than with how the agent was classified. Third-party and vendor-embedded agents are in scope on the same terms, and are the population where containment is usually more tractable than permission tuning.

§ 2 — In practice

Where the control lives decides whether it is one

Two facts frame this page. The EU AI Act contains no least-privilege provision: the phrase occurs nowhere in Regulation (EU) 2024/1689, verified by full-text search. And the framework that does recommend the practice recommends it. §2.1.2 of the IMDA Model AI Governance Framework for Agentic AI, version 1.5 of 20 May 2026, updated 5 June 2026, asks organisations to *define least-privilege policies that give agents only the minimum tools and data access needed for it to complete its task*, offering a coding assistant that may not need a broad web search tool where it already has curated access to documentation, and noting that structuring agents around functional boundaries acts as a natural constraint. Nothing enforces any of it.

"The agent has the database tool" is not a permission statement; it is the absence of one. A workable statement names three things — the tool, the verb and the object: which connector, read or write, and against what. The framework draws the verb boundary itself, asking that agents not be granted write access to tables in sensitive databases unless strictly required, and treating scope of actions as a primary impact factor: whether an agent can only read from, or can also modify, the data and systems it reaches. Most deployments scope by system. The customer platform is granted, and inside that grant sit record deletion, ownership transfer and mass update, none of which anybody enumerated.

The most quotable passage is about where a control lives rather than what it says. *Rather than instructing an agent not to use specific tools, access controls can be implemented at the tool layer to prevent those tools from being called in the first place, or only allowing them to be called in a certain way* — read access only being the given example. A system prompt listing forbidden tools is, on the framework’s own taxonomy, a non-deterministic limit, and a non-deterministic limit discharges nothing on its own: it triggers a requirement for compensating monitoring or human review to catch the failures. It is also, as the text notes, applied inconsistently across users in a way a system-level safeguard is not. The same distinction decides whether an action envelope is real at all — see bounding an agent’s authority. Where a risk is genuinely hard to express as a fixed rule, the framework is explicit that a model-based safeguard can be the more effective choice; that is a reason to choose deliberately, not a licence to default.

The Model Context Protocol is treated two ways at once, and both readings are sound. It is a risk source — the framework’s own illustration is deploying an untrusted MCP server containing code to exfiltrate a user’s data — and a candidate governance layer, because it sits between the agent and the enterprise systems it reaches, so controls can be defined there: filtering sensitive data that passes through the servers, logging all agent-to-system interactions, or whitelisting only trusted servers. The protocol guidance separately asks that any code execution be sandboxed. What an organisation cannot do is arrive at either position by accident, which is what happens when engineers add servers and nobody holds the register. The related omission is runtime control as a distinct class. Static configuration cannot express "this previously approved command is suspicious in this combination"; rate limits and input validation during execution are where that judgement has to live.

On exposure the honest answer is that there is none for this as such, and the indirect route is worth stating precisely so that nobody inflates it. For a high-risk system in the EU, an over-privileged agent is reachable through the cybersecurity limb of Article 15, which names data poisoning, model poisoning, adversarial examples and model evasion, and confidentiality attacks — and does not enumerate tool-permission failures. That route is indirect and arguable, and a page presenting it as a tool-permissions penalty is manufacturing one. For financial institutions the draft MAS Guidelines would place the same ground under existing headings: paragraph 4.16(b) on role-based access, multi-factor authentication and privileged account management, and paragraph 4.22(a) on reviewing the architecture, including APIs, plugins and third-party services, for access controls based on the principle of least privilege. Those are proposals in a consultation paper, not requirements.

§ 3 — What a weak answer looks like

A prompt is not an access control

The system prompt offered as an access control. It is well written, it lists the tools the agent must not use and the data it must not touch, and it has never been tested by attempting a forbidden call. On the framework’s own classification that is a non-deterministic limit, so even taken at face value it does not stand alone — it obliges the organisation to layer on monitoring or human review to catch the failures, which nobody has done because nobody registered the prompt as a control of that kind. The second half of the answer is usually a tool list, which records what the agent may reach and never what it may do there.

§ 4 — What discharges it

What the permission model must evidence

The artefacts an assessor asks to see, and what makes each one sufficient rather than merely present.

  1. 01

    A permission matrix at tool, verb and object granularity

    Exported from running configuration rather than transcribed from a design note, with read-only entries enforced at the connector. A matrix listing tools alone has recorded the grant and omitted its shape.

  2. 02

    A justification line against every write permission

    One sentence per write, naming who needs it and for which task. Writes accumulate during development for debugging convenience and are almost never withdrawn, so the unjustifiable ones are found by asking rather than by scanning.

  3. 03

    An MCP server register with a trust decision and an enforcement point

    Every server the agent can reach, who decided it was trusted, and whether an unlisted server can be reached at all. A register that no mechanism enforces is an inventory of intentions.

  4. 04

    A log entry showing a runtime constraint firing

    One real instance of a rate limit, validation rule or re-gating check stopping something during execution. Runtime controls are the class most often described in policy and least often observable in a log.

  5. 05

    A privilege-drift reconciliation, approved against running

    The approved set compared with what the runtime holds today, and the exception list that falls out. The exceptions are the finding: entitlements nobody approved, and credentials that outlived the task they were issued for.

  6. 06

    Segregation evidence between execution and reachable systems

    Where code executes, what that environment can reach on the network, and what it cannot. Sandboxing is recommended for code execution and is frequently asserted at the process level while the environment sits inside the corporate network.

§ 5 — Worked example

Worked example — the agent that was read-only on paper

A finance operations team runs an agent that chases invoice queries. It was given "the ERP tool" — a single service connector configured by the integration team — plus a document reader and, added later by an engineer, an MCP server exposing the payments sandbox. The design document says the agent is read-only. The connector’s credentials carry the same entitlements as the shared finance operations account, which can post journals.

Is the agent read-only, and what artefact would settle it?

Only in the design document, which is the wrong artefact to ask. Read-only is a property of the connector configuration and the credential behind it, not of a sentence in a specification, and here the credential can post journals. If the restriction lives anywhere at present it lives in the prompt, which the framework classifies as a non-deterministic limit — meaning it does not stand alone and imports a monitoring obligation nobody accepted. There are three separate findings. Granularity: the permission was expressed as a system, so the verbs inside it were never enumerated and no write is individually justified. Enforcement point: nothing at the connector prevents a write, so the running system and the approved design disagree. Provenance: the MCP server arrived without passing through any register, which means the trust decision for it was made implicitly by whoever added it. The fix is dull and effective — a second credential, scoped to read, with the write path removed rather than discouraged.

§ 6 — Elsewhere

The same requirement elsewhere

Where another instrument addresses the same obligation. These are correspondences, not comparisons — the Council does not rank one framework against another.

  • EU AI Act

    Article 15(5) requires cybersecurity measures appropriate to the circumstances for high-risk systems and enumerates specific attack classes. Tool-permission failure is not among them, so the route to it is indirect.

  • NIST AI RMF

    MAP 4 addresses risks arising from third-party software, data and components, which is the register question for tools, connectors and protocol servers an agent reaches.

  • MAS instruments

    The draft MAS Guidelines propose role-based access, multi-factor authentication and privileged account management for AI components in deployment, and architecture review against least privilege before go-live.

A correspondence indicates that two instruments address the same underlying obligation. It is not a mapping endorsed by either body, not a statement that one satisfies the other, and not a judgement about which is more demanding.

§ 7 — When it applies

Editions of the framework, not deadlines

  1. 22 January 2026

    Version 1.0 of the Model AI Governance Framework for Agentic AI, launched at Davos. Not an application date — the framework recommends and nothing attaches to an organisation that does not follow it.

  2. 20 May 2026

    Version 1.5, published 20 May 2026 and updated 5 June 2026. The current edition, and the one to cite: it separates platform providers from system providers, adds automation-bias practices and change management, and introduces the section on systemic and multi-agent risks.

§ 8 — provenance

The provision itself

This page sets out what the instrument requires and what discharges it. The official text is the authority — these go straight to it.

§ 9 — Also read

Also read

Certification

Assessed on the same standard of evidence

Every Council credential is examined on applied judgement against a published anchor, set out the way the obligations on this page are. The free AI Literacy Certificate is open to any adult today, and the register lists what is open for enrolment.

FreeAIAC AI Literacy Certificate30 minutes · identity verified · on the register
Open now →The credentials open for enrolmentThe register →