Stop Trying to Control AI Behavior. Control What AI Can Reach

You cannot reliably predict what an AI agent is going to do. That is a feature, not a flaw.

When things go well, developers can save a lot of time and effort. When it goes wrong, it can be disastrous. For example, in April 2026, a Cursor agent working on a staging task for PocketOS encountered a credential mismatch, found an unrelated Railway API token with blanket GraphQL permissions, and used it to delete the production database and its volume-level backups in nine seconds.

Unlike deterministic scripts, which produce fixed outcomes given the same input, we use agents because they can take a loosely defined objective and determine the steps themselves. An agent can read context, choose tools, query systems, revise its plan, and take a path nobody explicitly programmed. Security teams can decide afterward whether those actions were acceptable, but fully enumerating them in advance is not only antithetical to using an agent but also practically impossible.

On the other hand, you should be able to draw a map of every enterprise system the agent could actually reach. The number of systems your security team is responsible for securing is finite and knowable. It even comes with procurement receipts.

The way any system, deterministic or not, negotiates access is via credentials, like API keys, certificates, or passwords. If you find all the credentials available to an agent, you have effectively described what it can access. That could include cloud accounts, source control, SaaS platforms, databases, internal APIs, and MCP-connected tools.

Agents access those credentials from the local environments where they run.

The developer endpoint is part of the AI security perimeter

A developer workstation has always contained sensitive material. Developers keep credentials in .env files, configuration files, and environment variables. Tokens also end up in shell history, CLI configuration, and local development artifacts.

AI agents dramatically increase how much of that material can be discovered and used without deliberate human interaction.

An AI coding agent can reach those same locations because access to the local environment is part of how it gets work done. Ask an agent to troubleshoot an application and it may inspect and copy an environment file as it writes tests. Ask it to deploy something, and it may invoke a cloud CLI via the developer's credentials. Ask it to investigate an API failure, and it may test and log all credentials used to authenticate to see if that is the issue.

The developer did not need to explicitly tell the agent where the credential lived. Finding the information required to accomplish the objective is part of the job they delegated to the agent.

This creates a security problem that repository scanning or behavioral guardrails alone cannot describe. A secret can remain entirely local while still being available to an agent with access to the filesystem or terminal.

The GitGuardian State of Secrets Sprawl 2026 research found 24,008 unique secrets exposed in public MCP configuration files, including 2,117 valid credentials. AI-service credential leaks also grew 81% year over year.

Those numbers expose a much larger architectural issue. AI systems increasingly depend on credentials to connect models with the systems where useful work happens.

MCP makes agent reach much easier to expand

Ever since its introduction by Anthropic at the end of 2024, Model Context Protocol (MCP) has become one of the main ways developers have connected agents to tools. Anyone can give an agent access to a database, a development platform, or an internal service without building a bespoke integration.

Plugins and APIs extend that reach even further. Every useful connection gives the agent another potential path through the environment.

Credentials provide the authority underlying those paths.

An MCP server configured with a narrowly scoped development credential has a limited reach. Give that same server a long-lived credential with broad production permissions and the potential impact changes dramatically.

This is where counting agents or MCP servers stops being enough. Ten MCP servers with narrow permissions may create less risk than one server backed by an administrative credential.

Security teams need to understand the relationship between the agent, the tools it can invoke, and the authority sitting behind those tools. Everything the agent could touch is something a security team can discover, inventory, or constrain.

That gives us a much more practical way to talk about AI blast radius.

Credentials turn local AI access into enterprise authority

Imagine an agent discovers an AWS key while debugging an application.

The string itself tells us very little about the potential outcome. The permissions attached to that key determine whether the agent can inspect a development bucket, modify production infrastructure, or access sensitive data.

This is why secrets detection and identity context increasingly need to meet.

Finding a credential tells you there is a path. Understanding the identity and permissions behind it tells you where that path leads.

Teams need to build a centralized, living inventory of non-human identities and add context from the systems where those identities live. Teams should strive to identify admin and overprivileged identities across AWS IAM, Microsoft Entra, and Okta to fully understand what risks are associated with credentials connected to powerful identities.

That context needs to drive the AI security conversation.

A local credential with read-only access to a development system has one blast radius. A credential tied to an administrator has another. Security teams can prioritize the second case without knowing whether an AI agent will ever decide to use the credential.

The authority already exists. That is enough information to start reducing the risk.

Map what your agents can actually reach

The developer endpoint might not seem like the place to start the process of tightening controls to critical infrastructure, but it is where the most danger is concentrated.

Security teams should be embracing platforms that can discover credentials on developer machines and report those findings back to a central inventory. The underlying goal is visibility into local AI agents and MCP servers, including the tools and data available to them.

This creates a very different inventory from a traditional list of approved AI applications.

Knowing that Claude Code or Cursor is installed and which account the user is logged in with answers governance questions. Knowing which MCP servers are connected and which credentials are present on that endpoint starts answering the security question around access.

From there, teams can trace credentials into the environments where they are valid.

The result is a map of potential authority around the agent.

That map will change. Developers install tools. New MCP servers appear. Credentials get copied locally. Permissions accumulate.

Continuous discovery should be baked into any tooling. Security teams must maintain a way to keep updating the boundaries around AI without attempting to catalog every behavior the model might produce. This is not, and can not be, a one-off exercise.

Shrink the agent's potential blast radius

Once you can see the map, shrinking the risk becomes familiar security work.

First, remove credentials that should not need to exist locally. Rotate any exposed credentials.

After that, align this work with any larger efforts to move long-lived credentials toward more controlled or workload identity based authentication patterns. Separate development access from production authority. Ensure tools have only the minimum access required for the workflows they actually perform.

Each change eliminates possible paths through the graph.

An agent cannot use a production credential that is no longer sitting in a readable configuration file. A prompt injection attack cannot turn a read-only identity into an administrator. A compromised MCP server cannot exercise permissions its credential was never granted.

This approach also scales beyond any particular model vendor or agent framework.

Today the developer may use Cursor or Antigravity. Tomorrow they may use another coding agent. MCP servers and how we wire together services will undoubtedly change. Agent capabilities will keep expanding.

The credential layer still determines which enterprise systems those tools can authenticate to. Getting control of this layer should be at the heart of modern security programs.

Put controls at the moment an agent reaches for a credential

Some credentials will still need to exist because developers and agents need them to perform legitimate work. And there is the reality that developers are going to find a way, no matter the policy.

We need guardrails for the cases where an unexpected key is found or created.

Modern coding agents increasingly support hooks that can inspect actions while an agent is working. This is an ideal place to place some barriers to prevent the agents from using any found or derived keys. GitGuardian's AI Agent Hooks, for example. uses those hooks to inspect prompts, file access, commands, and MCP calls for secrets. Actions containing detected credentials can be blocked before the information reaches the model or tool.

This puts the control close to the credential boundary.

An agent can still choose how to solve the problem. It can explore files, invoke tools, and revise its plan. The control intervenes when that workflow attempts to expose protected credential material.

Security teams gain a useful enforcement point without needing to understand why the model chose that particular sequence of actions.

Make the worst possible AI decision boring

AI agents will get more capable and will act in ways that will become even harder to predict. They will continue to use more tools, interact with more systems, and perform increasingly complicated sequences of actions with less human involvement. Trying to enumerate the possible actions they can take is an unbounded assignment, and security teams do not have unlimited time.

Security teams do have a finite environment to protect.

There are only so many systems that can be accessed. There are only so many credentials created. There are only so many identities behind those credentials.

Focus on those paths and understand the authority behind them, and you will be on the path to better agentic security.

Remove the paths that should not exist and constrain the ones that need to remain.

The agent is going to be unpredictable. Our goal should be to make its worst possible decision boring from a security perspective.