An agent should reach only what its one job needs

Last Wednesday at Black Hat USA, a researcher from Novee Security showed that coding agents from Anthropic, Google and OpenAI could be turned against the companies that built them. The trigger was a single GitHub issue, the kind anyone on the internet can open, and it worked in the vendors’ own repositories under their default settings.

If the people who build these agents can get permissions wrong, so can you. That doesn’t mean you stop using agents. It means you decide, on purpose, what each one is allowed to touch.

What happened at Black Hat, in plain terms

All three tools were set up to read new GitHub issues and act on them automatically. An issue is just text that a stranger writes. The researchers wrote text that the agent treated as instructions.

The details differed by vendor. According to the Cloud Security Alliance’s write-up:

Claude Code’s command checker could be slipped past, and in the final version of the attack the agent used a pre-approved Hugging Face connection to leak an API key one character at a time through public download counters.
Gemini CLI, running without a person watching, trusted whatever files were in the workspace and checked its list of allowed tools when it started rather than each time it used one. Google rated the flaw 10.0, the top of the scale.
In a Codex setup with two passes sharing one folder, the first pass could rewrite the instruction file the second pass trusted.

Anthropic and Google shipped fixes. OpenAI treated its case as intended behavior and documented the file as untrusted input. The researchers also found similar default setups in well over a hundred other public repositories.

FlowHow one public issue became a leaked key

01Stranger opens an issue
02Agent reads it as instructions
03Agent runs a command
04Key leaks via an allowed tool

Every step used access the agent had been given on purpose.

The part I keep coming back to is the last step. The key didn’t leak through some exotic hole. It left through a connection the agent was allowed to use.

Your agents read strangers’ text all day

You may not run a coding agent on a public repository. But look at what business agents read. A support agent reads every inbound email. A sales agent reads web forms. An accounts payable agent reads invoices as PDFs. A research agent reads whatever web page it lands on.

Every one of those is text written by someone outside your company. Any of it can carry instructions. The Black Hat research shows that even agents built by the model makers themselves can follow them. So you can’t rely on the agent refusing bad instructions. You have to rely on what it can reach when it doesn’t refuse.

That turns the security question into a permissions question. If a support agent can only read the order history for the customer in the current thread and can only draft replies, the worst a poisoned email can do is produce a bad draft that a person rejects. If the same agent has an admin login to your store, a refund button and access to every customer record, the worst case is very different.

Before and after

Access set up for convenience

Shared admin login
Reads every customer record
Sends and refunds on its own
Can browse anywhere

Access set up for the job

Its own named account
Reads only the current customer
Drafts for a person to send
Talks to two approved systems

The same agent, with a very different worst day.

Four questions to answer for every agent

When I look at an agent before it goes live, I ask four questions. Write the answers down. If nobody can answer one, the agent isn’t ready.

What can it read? Name the systems and the records. “The help desk and the order system, for the customer in the ticket” is an answer. “Our data” is not. Most agents need far less than people give them, because it is easier to grant broad access than to work out the narrow version.

What can it change? Reading and writing are different risks. Start every agent in draft mode, where it prepares the email, the refund or the update and a person clicks the button. Move single actions to automatic only after you have watched a few hundred of them go right, and put a ceiling on each one, like refunds under a set dollar amount.

Where can it send things? This is the one most people skip, and it is the one that mattered at Black Hat. List every outside service the agent can reach, including ones that look harmless. The CSA note calls out approved third-party domains as a way to get data out. If your support agent has no reason to reach the open web, block it.

Whose credentials does it use? Give each agent its own account, the way you would a new hire, with its own name in the audit log. Never let it run on a founder’s login or a shared admin key. Use tokens that expire and cover only the systems on the list above. When something goes wrong, you want to switch off one account, not change every password in the company.

Some data should stay off every agent’s list until you have a specific reason and a person reviewing each use. That means payroll, bank logins, employee files, legal correspondence and anything covered by a contract that limits who can see it. An agent drafting support replies has no use for any of it. If a vendor’s setup screen asks for access to “all of Google Drive” or “the whole CRM,” stop and find out whether it can be scoped down to a folder or a pipeline. Often it can. The broad default is just the easiest one to set up.

ChecklistBefore an agent goes live

Read access is listed by system
It drafts and a person approves
Outbound links are listed
It has its own expiring login
Every action is logged and read

Treat the agent like a new contractor

The easiest way to get this right is to stop thinking of the agent as software and think of it as a contractor who started on Monday. You wouldn’t hand a new contractor the master password, the company card and the keys to every filing cabinet on day one. You’d give them what the job needs, check their work for a few weeks, and widen access as they earn it.

The eSecurity Planet summary of the research lands in the same place: least-privilege permissions, separate workspaces between runs, treating generated files as untrusted, and re-checking agent behavior whenever software or default settings change. That last one matters for small companies. Your vendor will update its defaults without asking you. Put a reminder on the calendar to re-read the settings every quarter.

What to do this week

List every agent or AI automation running in your company, including the ones a team set up with a no-code tool. One line each.
For each one, write which account it runs under. Flag any that use a person’s login or a shared admin key, and give them their own accounts first.
For each one, list every system it can read, every action it can take on its own and every outside service it can reach.
Cut anything on those lists the job doesn’t need. Move any action that sends money or messages out the door back to draft mode until you’ve reviewed its history.
If you use Claude Code or Gemini CLI in automated GitHub workflows, check that you are on the patched versions and rotate any keys those workflows could see.