An AI agent with tools behaves less like a chatbot and more like an insider account. It can read, decide and act across systems at machine speed. The security design must therefore start with authority: what the agent can reach, what it can change and how quickly the team can stop it.
Reading a document is an action. So is running a command, installing a package, querying a customer database, sending an email or calling an API. Each tool turns a model response into a change in the world. The useful question is therefore not whether the model is intelligent enough to use a tool. It is whether the system has limited what that tool can do when the model is wrong, manipulated or operating on compromised inputs.
That distinction now matters in production.
Anthropic's analysis of the GTG-1002 cyber-espionage campaign describes an operator using an AI agent to chain reconnaissance, exploitation, lateral movement and data collection. The model was dangerous because the surrounding software gave it tools, continuity and room to act across several stages of an intrusion.
Software supply chains show the same pattern from another direction. GitHub reported a sustained wave of attacks against package repositories and CI/CD systems. Its 2026 response included safer workflow defaults, staged npm publishing, tighter trigger controls, restrictions on install scripts and faster credential revocation. Those controls do not depend on every developer or automated process making a perfect decision. They limit what one compromised account, package or workflow can do next.
Agents need the same treatment.
The model is one part of the attack surface
Teams often review the model, prompt and output while paying less attention to the execution environment around them. The larger risk sits in the combination:
- The files and records the agent can read
- The commands and tools it can invoke
- The credentials available during a run
- The packages and external services it can introduce
- The actions it can complete without approval
- The memory it can carry into later sessions
A prompt injection hidden in a web page or document may look like data to a human and like an instruction to an agent. NIST describes this as agent hijacking: untrusted content enters the same context as trusted instructions and redirects the agent toward an unwanted action.
The model may also make an ordinary mistake. It can target the wrong environment, misunderstand the requested scope or select a package with a deceptive name. Security cannot rely on the agent recognizing every trap. The surrounding system must make a bad decision cheap to stop and small enough to recover from.
Start with an authority map
Before deployment, write down the agent's authority in operational terms.
For every tool, specify what the agent may read, propose, change and release. Name the conditions that require a person. Name the person who owns the exception. Decide how the action will be reversed.
“Access to GitHub” is too broad. A useful authority definition might allow an agent to read two repositories, create a branch and open a draft pull request. It would deny changes to branch protection, repository secrets, billing, membership and production releases.
“Access to finance” is equally vague. An accounts-receivable agent may read approved invoice records and prepare follow-up drafts. It should not change bank details, issue refunds or release payments with the same identity.
This map exposes dangerous combinations. An agent that can read untrusted content, retrieve production credentials and execute arbitrary commands has several stages of an attack chain in one session. Separate those powers before refining the prompt.
Give each run the smallest useful identity
Agents should not borrow a founder's or administrator's standing access. Give the agent its own identity, then bind credentials to the task, resource and time window.
A research run may receive read-only access to a defined folder for 30 minutes. A deployment run may write to a staging environment but require a separate approval for production. A support agent may retrieve one customer's records after the ticket system provides a verified customer identifier.
Short-lived, workflow-bound credentials reduce the value of anything an attacker extracts. They also produce cleaner logs because actions belong to a named agent and run instead of disappearing under a shared human account.
Least privilege is not a one-time configuration. Tools, integrations and job scope change. Recheck permissions whenever an agent gains a new data source, model, package manager, memory store or execution tool.
Separate preparation from release
Most useful agent work has a reversible preparation stage and a consequential release stage.
Let the agent prepare the email, payment batch, database migration, infrastructure plan or package update. Run checks on the prepared result. Require a policy check or human approval before the system sends, pays, migrates, deploys or publishes.
The approval should show the actual proposed action, affected resources, evidence used and expected impact. A button labelled “Approve” beside a vague summary creates ceremony, not control.
Approval gates also need thresholds. A support agent might send an approved template automatically but escalate any message containing a refund, legal claim or account closure. A coding agent might merge a documentation fix after tests pass but stop when a change touches authentication, dependencies, secrets or infrastructure.
The point is to reserve attention for consequences, not to place a person in every loop.
Treat packages and tools as executable authority
Package installation is remote code intake. An agent with permission to select and install dependencies can import someone else's software into the environment, often with scripts that execute during installation.
Pin versions. Use lockfiles and allowlists. Verify package provenance. Disable install-time scripts by default where the ecosystem permits it. Scan the dependency and run it in an isolated environment before it reaches sensitive credentials or production data.
Apply the same discipline to agent tools and MCP servers. A tool description is not a security boundary. Verify where the tool came from, what code runs, which network destinations it can reach and which credentials it receives.
Supply-chain safety improves when trust takes time. GitHub's package cooldowns and staged npm publishing create a gap between a new release and broad execution. Agent workflows can adopt the same idea: quarantine new tools and dependency versions until checks and observation establish a reason to trust them.
Log decisions, tool calls and effects
Chat transcripts are not sufficient audit logs.
Record the agent identity, run ID, initiating user, model and tool versions, data sources, requested action, parameters, approval decision, resulting system change and error state. Protect the logs from the same agent being monitored.
Good logs answer practical questions during an incident:
- Which files did the agent read?
- Which commands ran and with what arguments?
- Which credentials or roles were active?
- What left the network, and where did it go?
- Who approved the consequential action?
- Which later runs reused the affected output or memory?
NIST's current work on agent systems places strong emphasis on constrained access, monitoring and machine-readable audit trails. That evidence supports both accountability and faster recovery.
Design rollback before autonomy
Every production agent needs a stop path and a recovery path.
You should be able to revoke its credentials, end active sessions, block network access, isolate generated artifacts and identify every system it changed. Mutable actions need backups, version history, transaction boundaries or compensating actions.
Test the rollback. A written procedure that depends on the same compromised credentials, unavailable administrator or damaged logs will fail when needed.
A simple pre-deployment exercise is useful: assume the agent follows a malicious instruction in the next document it reads. Ask what it could access, what it could change, how far the change could propagate and how long the team would need to detect and reverse it. The answers reveal the real blast radius.
Governability is a deployment capability
Agent security does not require removing useful tools. It requires making authority explicit.
The strongest production pattern is controlled execution: narrow identities, isolated environments, trusted inputs, staged actions, meaningful approvals, protected evidence and rehearsed rollback. Nexius Labs describes the wider operating discipline as Human Control and Mission Control, where agent work has named ownership, bounded authority and visible escalation.
Start with one workflow. List every tool and permission. Remove standing credentials. Separate preparation from release. Add logs that capture effects, then run a rollback drill before increasing autonomy.
An agent can move quickly without holding the keys to everything.
Sources
- Anthropic: Mapping AI-enabled cyber threats
- GitHub: Disrupting supply chain attacks on npm and GitHub Actions
- NIST: Securing AI agent systems
- NIST: Strengthening AI agent hijacking evaluations
Originally published by Nexius Labs on Medium: Agent Security Is an Authority Problem.
Top comments (0)