Nodal
AI Agent Permission Blueprint

Most companies don't know what their AI agents are actually permitted to do. Here's what that gap looks like.

A practical breakdown of the AI agent permission gaps I see most often — across financial services, recruitment, logistics, legal, property, and advertising. And five questions every business should be able to answer about every agent they run.

Most companies deploying AI agents know what they're supposed to do. Very few know what they're actually permitted to do.

AI agents are running in production across every sector — handling customer queries, processing documents, making scheduling decisions, contacting people on behalf of businesses, optimising spend, screening applicants. The teams that deployed them know what these agents are supposed to do. Very few can tell you what they're actually permitted to do — and the gap between those two things is where operational, legal, and reputational risk accumulates.

This isn't a technology problem. It's a governance problem. The agent was deployed when it worked in testing. Nobody defined what it was authorised to do when it hit an edge case, encountered something ambiguous, or made a decision at a scale nobody anticipated.

66%

of companies are deploying AI agents without a governance layer in place — despite 100% planning to expand agent use. Only 34% cite governance as a top evaluation factor. The agents are running. The rules were never written. CrewAI State of Agentic AI, 2026.

Five permission gaps that show up in almost every AI deployment I review.

These aren't hypothetical or sector-specific. They appear repeatedly across financial services, recruitment, logistics, legal, property, and advertising — whenever I map what agents are actually authorised to do versus what the team assumed.

GAP 01
Permissions were never explicitly decided — they defaulted

The most common finding across every sector. The agent's permissions weren't consciously set — they defaulted to whatever the platform allowed when it was connected. No record of the decision, no owner, no review date. The agent is running within whatever technical scope the integration happened to provide.

GAP 02
No approval threshold for autonomous actions

The agent can make decisions — contact people, move money, reschedule bookings, send communications, process requests — up to an undefined limit. Because nobody set a limit. The threshold for when a human should be involved was never documented. The platform defaulted to full access within its technical scope.

GAP 03
Escalation path exists in theory but hasn't been tested

There's a named person or team for escalation. Nobody has run a scenario where the agent actually hits the trigger. The path may already be broken — a stale Slack channel, a person who's moved roles, a procedure written six months ago and never revisited. Nobody will know until it matters.

GAP 04
No documented pause or kill procedure

If an agent starts doing something wrong at scale — incorrect decisions, looping on edge cases, contacting the wrong people, misallocating budget — how do you stop it? Most teams don't have a written procedure, a named decision-maker, or a tested mechanism. At the speed AI agents operate, "we'd figure it out" is already too late.

GAP 05
Token spend isn't monitored per agent

A spike in token spend per agent is usually the first signal that something is wrong — the agent is looping, hitting unresolved edge cases, or operating outside its intended scope. It's the earliest operational warning available. Most teams don't track it per agent, so they miss it entirely.

What the permission gap looks like when it surfaces.

The pattern — across every sector

An AI agent is deployed because it works in the expected scenario. It handles the standard cases well. The team is pleased. Nobody defines what it's authorised to do when it encounters something outside the expected scenario — because in testing, it never did.

Three months later, something changes. A volume spike. An edge case. A connected system behaves unexpectedly. The agent makes a decision — or a series of decisions — that nobody authorised. By the time someone notices, the damage has already happened at scale. The agent wasn't malfunctioning. It was doing exactly what it was technically permitted to do. Nobody had defined the boundary.

In financial services: 800 refunds processed with no approval threshold, no audit trail.
In recruitment: 2,400 candidates contacted with undocumented screening criteria, ICO complaint filed.
In logistics: time-critical deliveries rescheduled autonomously, client SLAs broken before anyone sees it.
In legal: AI-produced summary with a material error reaches a client, no documented review gate existed.
Same gap. Different sector. Different consequence.

The failure isn't the AI doing something wrong. It's the absence of a documented decision about what it was permitted to do in the first place.

Five questions you should be able to answer about every AI agent you run.

These apply regardless of sector. If you can't answer them cleanly for every agent in production, the permission gap is real.

01
Was every permission this agent has explicitly decided — or did it default to whatever the platform allowed when it was connected?
If you can't point to a documented decision, the answer is "defaulted." That's a finding in every assessment I run.
02
What is the maximum operational, financial, or reputational impact this agent can have autonomously — before a human is involved?
Most teams can't name a number. The agent's scope is technically bounded, not operationally bounded. Those are different things.
03
If this agent made the same incorrect decision 500 times before anyone noticed — what would the damage look like, and how far would it travel?
Quantify it. Vague answers mean you haven't mapped the failure scenario. In connected systems, one agent error travels further than the agent itself.
04
Who is the named person who stops this agent right now if something is wrong — and have you tested that the procedure actually works?
An untested escalation path is not an escalation path. It's a plan that might work. The test needs to happen before the incident.
05
Do you track token spend per agent — and do you have a threshold that triggers a human review?
Token spend is your earliest operational warning signal. A spike usually means the agent is looping or hitting edge cases before any other signal surfaces. Most teams miss it entirely.

The Trust Readiness Score — six pillars, scored out of 30.

Every Nodal assessment produces a Trust Readiness Score across six pillars, scored out of 30. Most teams I assess score between 6 and 14 on first review — meaning they're in the At Risk or Exposed band. Here's what each pillar typically looks like before a governance layer is in place.

Workflow Clarity
Typically: undocumented. Agent purpose described informally — no written scope, boundary, or named owner.
Agent Authority
Typically: defaulted. Permissions set by whatever the platform allowed at setup — not a conscious operational decision.
Human Oversight
Typically: assumed. Someone reviews outputs informally — no documented mandatory checkpoint before the agent acts or communicates.
Escalation Architecture
Typically: informal. Named person for escalation — no documented trigger conditions, no tested procedure, no SLA.
Failure Preparedness
Typically: absent. No mapped failure scenarios, no quantified impact, no documented "what if this goes wrong at scale."
Operational Resilience
Typically: ad hoc. No written stop procedure, no named incident owner, no tested mechanism to pause a misbehaving agent quickly.

Three ways to continue.

Get your free Exposure Report. Six questions about your current AI setup. Your Trust Readiness band comes back immediately with a breakdown of where the gaps typically sit for your score.
Book a free 30-minute call. I'll ask you six questions about your AI setup and tell you exactly where your permission gaps are.
Read more about the Nodal Trust Assessment. A structured review that maps what every agent can do, where permissions are missing, what failure looks like, and what needs to change — delivered in 5–7 working days.