Treat Agents Like Interns, Not Admins

When a junior joins, you don't give them admin access to everything on day one.

The right thing to do, as with any employee, is to give them exactly what they need to do their job, and nothing more.  We've spent decades building sophisticated permission structures to protect our businesses from accidental or malicious acts around one simple principle: least privilege access.

So why, when we deploy AI agents, should we suddenly forget everything we've learned?

Right now, across organisations deploying MCP servers, n8n workflows, and custom automations, I fear that there is a dangerous pattern emerging. Teams are giving agents broad, permissive access to systems and data (or simply having the agent use their credentials) because it's easier and because the agent "needs to be helpful across lots of different tasks" or simply because they don’t know any better.

That's the equivalent of hiring an intern and giving them a notebook with all your usernames and passwords.

Agents are powerful. They can automate real work, accelerate analysis, and free your team to focus on the problems that actually require human judgement. But they are not administrators. They are not trusted employees with years of track record. And unlike an intern, they will never earn that trust in the same way a human does because they do not grow on their own. They need a defined scope, and they need to stay in it.

The breaches are already happening

This isn't a theoretical concern. The evidence is accumulating in real time.

In June 2025, researchers disclosed EchoLeak (CVE-2025-32711), a critical zero-click vulnerability in Microsoft 365 Copilot rated 9.3 out of 10 on the severity scale. An attacker simply sent a crafted email. Copilot ingested it during routine summarisation and followed the hidden instructions, automatically pulling files from OneDrive, SharePoint, and Teams, then transmitting them to an attacker-controlled server. No malware. No user clicks. No alerts. The attack worked precisely because Copilot had broad access to everything in the M365 environment. One email. Everything it could reach was in scope.

In April 2026, startup founder Jeremy Crane watched his company's production database and all its backups disappear in nine seconds. His Cursor agent, running Claude Opus 4.6, had encountered a credential mismatch in the staging environment and decided to fix it. It went looking for an API token, found one sitting in an unrelated file, and used it to call delete on the production volume. The token had been created for managing custom domains but was scoped for everything. The agent didn't ask. It just acted.

Railway (Pocket OS’s cloud provider) stepped in and recovered the data, but the lesson is clear: the agent didn't go rogue. It did exactly what an agent with admin-level access does when it decides to solve a problem.

In each case, the vulnerability wasn't in the agent's code. It was in the permission structure that gave it access to data it should never have seen.

The approved tool trap

"We already use this tool, so the AI features built on it must be fine."

Sounds logical. Sadly, it’s wrong.

When your organisation approved a tool, it approved it for specific purposes with specifically scoped access and data. The new AI features which are often driven by agents under the hood, allow you to create your own agents and the workflows you may be connecting them to weren't part of that original assessment. They may route data differently, surface information in ways that cross boundaries that have not been fully considered. The tool being approved doesn't automatically extend to every agent you use or build with it.  

This approved tool trap is the most common mistake I see in agent deployment and is entirely avoidable.

The framework: Treat agents like employees

A long walk and a bit of thinking got me there: this is much simpler than I expected. You apply the same thinking to non-human workers that you apply to human ones.

Step 1: Define the agent's job in one sentence.

Not "what could it theoretically do." Not "what might be useful someday." What specific job is this agent being created to accomplish today? If you can't articulate it in a single, clear sentence, you're not ready to define its permissions.

"This agent answers customer questions about flight schedules by querying our schedules database" is good. "This agent helps people with aviation data" is not.

The job description immediately suggests what data the agent needs and what it doesn't.

Step 2: Grant minimum access, nothing more.

For each agent, document what it actually needs to read. Does it need write access at all? Default answer is no.

A schedules query agent needs schedules data. It does not need pricing data, capacity planning documents, customer contracts, or HR records. Giving it access to all of that might feel like you're building a super-useful all-in-one agent. You're not. You're creating risk.

The risk is two-fold.

The first is blast radius. If an agent gets manipulated through prompt injection, hallucinates, or just gets confused, whatever it can read it can leak, and whatever it can write it can break. A narrow agent has a small blast radius. A broad agent has a huge one. It's the same reason you don't give every new joiner admin access to every system on day one.

The second is performance. The more access you grant, the more context the agent loads to do its job. A bloated context window makes hallucination more likely, not less. The agent gets dumber the more you give it. And if it does lose the plot, you've now got an agent with a fogged-up brain holding the keys to everything.

Step 3: Use unique credentials per agent.

Never share API keys or service accounts across agents, even if they seem similar. Each agent should get its own credentials, scoped to its own role, just like you would a human employee. Store them in a vault and never hardcode them in workflow definitions or configuration files.

This sounds obvious if you've spent time in software engineering. But when anyone with an n8n account can spin up an agent in twenty minutes, credential hygiene is the last thing on their mind. I can guarantee it's not as obvious as it looks.

Step 4: Monitor for what "normal" looks like, then alert on deviations.

Establish baseline behaviour for each agent after deployment: how many queries per hour, which data types accessed, what time of day it's most active. Then set alerts for deviations. For example, 3X normal query volume warrants a warning. 10X normal volume warrants automatic rate limiting and immediate investigation. Access to data types the agent has never touched before warrants immediate attention.

Failed permission attempts are either bugs or attacks. Either way, they require investigation, not silence.

Step 5: Review permissions regularly, and revoke immediately when an agent is retired.

Agent permissions aren't set-and-forget; regular reviews catch access that's no longer needed. And when an agent is decommissioned, revoke its credentials the same day.

Why granular permissions are worth the effort

The pushback I expected was "This sounds like a lot of overhead. We'll have dozens of permission configurations to manage."

But in reality, I got a very different response because the options are not hard to choose between:

• Option A: upfront effort to define agent roles, ongoing maintenance as agents evolve, and a more complex architecture to document.

• Option B: fast deployment, simple setup, until the breach. Then: customer notifications, late nights, early mornings, potential regulatory investigation, potential fines of up to 4% of annual revenue, forensic investigation across all affected systems, and reputational damage that takes years to repair.

The complexity argument is backwards. Each distinct permission configuration is a firebreak: a place where a security failure stops rather than cascading across your entire data ecosystem. If a single agent gets compromised and has access to your entire customer database, your financial records, and your file systems, your incident response team has to investigate everything simultaneously. If the same agent only has access to customer support tickets, your investigation focuses on one system.

Proper permission structures aren't overhead, it’s a classic situation where rushing to get something live comes at the costs of building a resilient, safe and auditable system.

What this means if you’re building agents right now

Agents deserve the same scrutiny you'd apply to a new employee, no exceptions.

They can do real work and are genuinely valuable. But they're not trusted colleagues with institutional knowledge, full contextual awareness and as a result lack consistently good judgement when faced with ambiguity. They're new to the job. Give them exactly what they need to do it, nothing more.

1. Define the job.

2. Map the minimum data.

3. Provide unique credentials.

4. Monitor behaviour.

5. Review regularly.

That’s the framework. It doesn’t look like much, but it saves real time and real pain. The organisations getting this right now will have a meaningful advantage when agentic AI becomes standard, because they’ll have avoided the breaches, and built foundations their customers, regulators, and boards can actually trust.

The Builders Blog is a practitioner-first publication on AI, aviation data, and building things that actually work. Subscribe to The Builders Blog LinkedIn newsletter here.