5 MCP servers live now What’s live ›
Real Biz Digital logo Real Biz Digital

AI governance

How to scope AI agent permissions

Most AI agents in production hold whatever permissions belonged to the account their integration was configured under. That boundary was not designed — it was inherited. It usually covers every record the account could reach, every transaction value, every counterparty, and it was set by someone solving a connectivity problem, not a governance one. The result is a system that can take a €200,000 action because it needed to take a €200 one, and an authority boundary that nobody in the organisation ever approved.

How Barzel applies here Start free with BarzelVault

Why do existing user roles not transfer to AI agents?

Role-based access control was designed around human job functions: what does a finance clerk need across a working day, across all the cases they might encounter? That model tolerates broad grants because a human applies judgement inside them.

An agent breaks two assumptions that make RBAC work.

It does not apply judgement to the grant. A human with permission to issue credit notes does not issue four hundred of them because a data feed was malformed. The role was broad because the human was the control.

It needs a narrower set than any role expresses. An agent reconciling invoices needs to read ledger entries and flag mismatches. The finance role it inherits also lets it post journals, change bank details and issue payments. Everything in that gap is standing privilege with no corresponding need.

Roles also cannot express the dimensions where agent risk actually concentrates. There is no role for "may issue invoices up to €5,000 to counterparties existing more than 90 days".

What are the four dimensions of AI agent permissions?

A workable agent permission is a conjunction across four axes, not a single grant.

1. Action type

Which operations, named individually. Not "write access to the finance system" but "may create draft invoices; may not post them; may not modify bank details". The distinction between read, propose and commit is the single highest-value split, because it lets an agent do most of its work with no ability to cause an irreversible effect.

2. Value

A monetary or quantitative ceiling per action and, separately, per time window. The per-window limit matters more than most teams expect: an agent constrained to €5,000 per action can still issue two hundred of them in ten minutes when its input data is wrong.

3. Counterparty

Which entities the agent may act toward. New counterparties, counterparties whose bank details changed recently, and entities outside the usual jurisdictions are where fraud concentrates — and none of them are caught by a value ceiling, because the amounts look ordinary.

4. Data classification

Which data classes the agent may read and which tools it may reach with them. The NSA's MCP guidance is explicit here: segregate tools by data classification so public tools handle public data and sensitive data has restricted access. In practice this means an agent that summarises public documentation should not be reachable from the same context as one that touches customer records.

Scope creep is a named regulatory risk

This is not a theoretical concern. FINRA's 2026 Annual Regulatory Oversight Report discusses AI agents directly and names scope creep beyond intended authority as a supervisory risk, alongside autonomy without human validation, auditability of multi-step reasoning, sensitive-data disclosure and misaligned reward structures. Its recommendations are human-in-the-loop protocols, tracking mechanisms and behavioural guardrails.

The mechanism is worth understanding because it is not misbehaviour. An agent given a goal will take instrumental steps toward it. Asked to clear an ageing debtor report, closing accounts and issuing credit notes are reasonable steps. The agent is not exceeding its instructions — it is exceeding the authority someone assumed those instructions implied. The fix is not a better prompt; it is a boundary the agent cannot argue with.

Enforce outside the agent

If the agent evaluates its own permission boundary, the boundary is part of its context — and anything that can influence its context can influence the boundary. That includes content the agent reads. An untrusted document that reaches the model's context and instructs it to treat a limit as raised has, in that architecture, raised the limit.

This is why the NSA guidance treats all tool output as untrusted input to the next phase of the pipeline, and it is why permission enforcement belongs in a layer the agent passes through and cannot reconfigure. The practical test: if changing the system prompt could change what the agent is allowed to do, the permission is not enforced.

A useful secondary property of external enforcement is that it survives model changes. Constraints expressed in prompts are re-litigated with every model upgrade; constraints expressed in a gateway are not.

How long should an AI agent's credentials live?

The NCSC's May 2026 guidance on adopting agentic AI recommends least privilege, ephemeral credentials, monitoring, AI-specific incident response, modelling failure modes before connecting to live data, and explicit human accountability chains. The ephemeral-credential point deserves emphasis because it is cheap and rarely done.

A long-lived token held by an agent process is a standing capability that persists across every task, including tasks nobody anticipated. A credential minted for a specific task, scoped to that task's needs and expiring with it, converts a permanent capability into a bounded one — and it means a compromised agent context yields access to one task's scope rather than the whole integration's.

Where the underlying system supports it, this is also where protocol-level improvements help. The MCP 2026-07-28 specification bound client credentials to the issuer that minted them, preventing reuse across authorization servers — a narrower blast radius by construction. See the MCP security analysis for what that release does and does not solve.

A worked scoping example

An agent that handles supplier invoice queries. The inherited grant is "finance system user". A scoped grant:

DimensionGrant
Action typeRead invoices and payment status; create draft correspondence; propose credit notes. May not post, pay, or modify supplier master data.
ValueProposals up to €2,000 auto-approved; above that, human approval. Cap of €20,000 proposed in any rolling hour.
CounterpartySuppliers active more than 90 days with unchanged bank details. Anything else routes to a human.
Data classInvoice and payment data only. No access to employee records, contracts or credentials.
CredentialsTask-scoped, expiring at task completion or 30 minutes.

Note what this preserves: the agent still does the work. What it cannot do is cause an irreversible effect without either staying inside a bound someone approved, or routing to a person. That is the whole design goal — approval thresholds handle the exceptions.

Frequently asked questions

Why are role-based permissions insufficient?

Roles express what a job function needs across a day; agents need a narrow task-specific set. Roles also cannot express value, counterparty or data-class limits, which is where agent risk concentrates.

What is scope creep?

An agent taking actions beyond intended authority as instrumental steps toward a goal. FINRA's 2026 oversight report names it as a supervisory risk.

Should permissions be enforced in the agent or outside?

Outside. If a prompt change can change what the agent may do, the permission is not enforced.

What does the NSA recommend?

Least privilege for agent processes, OS-level sandboxing, and tool segregation by data classification.

Are ephemeral credentials worth the complexity?

Usually yes. They convert a permanent capability into a bounded one and limit what a compromised agent context yields.

Related

BarzelVault enforces permission scope as a layer in front of the agent, evaluating action type, value, counterparty and data class before execution — and recording the decision either way.

In practice

Permission before the action. Evidence after it.

The duties on this page attach to the moment an automated system acts: who permitted it, on which data, under which policy version, and what a person saw before approving. Barzel enforces that decision before execution and writes the record an auditor, a regulator or a data subject can be shown.

430 days leftEU AI Act high-risk obligations (Annex III) apply from 2 December 2027

BarzelVault

The AI action firewall: decide what an agent may do before it does it.

  • Approval thresholds and policy checks enforced before execution; human approvals that expire and escalate.
  • Cryptographically signed audit receipts: trigger, inputs, policy version, approver, outcome.
  • Credential isolation, spend and action limits, and an emergency kill switch.

Free tier: 10,000 calls a monthPaid plans from $199 a monthLive on MCPize

Start free Ask by emailProduct pageDocumentation

Barzel Central Gateway

The AI governance control plane: one inventory and one policy layer across every MCP server and agent.

  • Registers and synchronises every tool; enforces identity, policy, region, cost and health per tool.
  • Identity mapping through OIDC, Entra ID, Okta, SAML and SPIFFE, with credential brokerage.
  • Trace and SIEM export (W3C trace context, OTLP) for the security team and the regulator.

Free tier: 1,000 calls a monthPaid plans from $10 a monthLive on MCPize

Start free Ask by emailProduct pageDocumentation

Enterprise: written quote by email within two business days. No sales call.

Sources

  1. FINRA, 2026 Annual Regulatory Oversight Report, generative AI section.
  2. NSA, CSI: Model Context Protocol (MCP) — Security Design Considerations for AI-Driven Automation, Ver. 1.0, May 2026.
  3. NCSC, Thinking carefully before adopting agentic AI, 15 May 2026.
  4. Model Context Protocol, 2026-07-28 specification (client credential binding).

This article is for information and does not constitute legal or security advice.