TL;DR

• A framework for measuring autonomy: The Cloud Security Alliance's six-level model (Level 0 to Level 5) gives security teams language for how independently an AI agent can act, from human-executed tasks to full autonomy.
• Credentials reveal an agent's real reach: Intended boundaries often don't match actual access. GitGuardian found AI-service credentials rose 81% to over 1.27 million, and 64% of credentials valid in 2022 were still active in January 2026.
• Detect, remediate, prevent: GitGuardian's Developer Endpoint Protection and AI hooks inventory agent access, rank credentials by risk, and block secrets from spreading through tools like Claude Code, Cursor, and Copilot.

What is AI autonomy?

Merriam-Webster defines autonomy as "the quality or state of being independent, free, and self-directing." Historically, this has applied primarily to people. But like all terms, the definition will continue to evolve with the culture that coined it. Today, that means dealing with agentic AI. 

When we talk about AI autonomy, we need to limit this definition a bit further. For AI agents, it means how much an AI system can pursue a goal without direct human involvement. 

At lower levels, a person still directs most of the work. The system recommends an action, drafts content, or performs a tightly bounded task. At higher levels, an agent can build a plan, select tools, execute several steps, react to results, and keep working toward an objective with limited human input.

While anecdotally, we can sort any actions based on how much a human is involved, we need a framework that helps us communicate levels of human involvement. 

Five-level framework of AI autonomy

Fortunately, groups like the Cloud Security Alliance have been working on this problem and proposed a useful five-level framework. The model intentionally takes inspiration from the Society of Automotive Engineers' levels of vehicle automation, where increasing autonomy is paired with different expectations for oversight, governance, and control.

The CSA framework runs from Level 0 through Level 5:

• Level 0: No Autonomy
• Level 1: Assisted
• Level 2: Supervised
• Level 3: Conditional
• Level 4: High Autonomy
• Level 5: Full Autonomy

This framework gives us a useful language for recognizing that progression, from Level 0 human execution through Level 5 full autonomy. The goal is not to force every agent into a rigid governance tier. It is to understand what agents can actually do today.

That requires looking beyond prompts and stated policies to the credentials and access paths underneath them. 

This means one of the more critical questions security teams need to ask about an agent is "What data and systems can it reach, and what elevated autonomy would that grant it?"

Organizations need to detect any exposed credentials across the credential layer, remediate any access that creates unnecessary risk, and prevent agents from gaining or spreading plaintext credentials that expand their reach even further.

Types of AI autonomy

The CSA framework gives organizations useful language for recognizing increasing autonomy. It should be read as a spectrum of how human involvement changes as an agent becomes capable of acting more independently.

The CSA calls out Level 3 as the point where things get especially interesting, where humans define boundaries, and the agent makes decisions independently inside them. Those boundaries could involve environment, action type, financial value, or other conditions. These boundaries need technical enforcement.

A policy may say that an agent is restricted to development. If the credential available to that agent can authenticate to production, the technical environment allows more than the intended boundary.

The agent has potential reach beyond the autonomy the organization believes it granted.

The same thing happens when an agent intended to modify one repository inherits an organization-wide token, or when an assistant expected to work with local files can call a cloud CLI already authenticated as the developer.

The assigned autonomy level is only part of the picture.

Teams also need to understand the effective authority the system makes available to the agent, especially if it is unintended.

4 credential risks associated with AI autonomy

Every useful agent eventually needs access. Reading a repository, querying a service, or calling an API to talk to a database all require authentication and authorization, which we have traditionally delivered via credentials. These secrets, in the form of keys, tokens, and certificates, connect those agents to the rest of the enterprise.

That makes credentials a useful way to uncover autonomy that may otherwise remain invisible.

Caption: Your Credential Layer flows through your developer laptops

1.Reach

Start with knowing which systems the agent can authenticate to. This includes credentials intentionally configured for the agent and credentials sitting within its environment.

A coding agent might have a GitHub token explicitly added to its configuration. It may also run on a developer laptop containing AWS credentials, SSH keys, database passwords, package registry tokens, browser sessions, .env files, and an already-authenticated cloud CLI.

The agent's reach can therefore extend well beyond the credentials anyone remembers assigning to it.

One credential can, and probably will, easily lead to another. An agent with access to a repository can find a hardcoded database password. The database may expose another token. An MCP server may pull a secret into a local configuration file.

Credentials create paths through an organization. Understanding the agent means understanding those paths.

2.Frequency

Autonomy also changes how quickly that authority can be exercised.

At CSA Level 1, a human approves each action. At Level 2, one approved plan may unleash dozens of credential-backed actions. 

At Level 3, those actions continue without approval as long as the agent believes it is within its boundaries. Level 4 can turn that authority into continuous machine activity.

A credential originally issued for occasional human use can suddenly support hundreds of automated requests. The danger comes from the agent, which had not yet found or used these keys, changing behavior unexpectedly and treating those secrets as a path to accomplishing a seemingly unrelated goal. 

3.Review

Human review gets further away from individual actions as autonomy rises.

A person may believe they are reviewing what an agent is going to do because they approved the initial task. The actual workflow can contain dozens of intermediate decisions, tool calls, file reads, and authenticated actions that were never individually reviewed. This is especially important with agentic systems because the exact execution path can change from run to run.

Security teams need visibility into the authority available before those paths are chosen.

4.Persistence

Agents are often very temporary while their credentials are extremely long-lived. GitGuardian found that more than 64% of credentials confirmed valid in 2022 remained valid when retested in January 2026. This is much longer than any AI agent using a current model could have been running. 

A developer may add a token to make an agent work for one afternoon. The configuration survives. The token survives. Another tool discovers it later.

What looked like temporary access becomes part of the standing credential layer.

Mapping AI agent autonomy level vs credential risk

The CSA framework becomes especially useful as a diagnostic tool when we combine the levels with known risks brought by secrets.

This is a good place to remind ourselves that the goal is not to look at every agent and simply stamp "Level 2" or "Level 3" on it. A useful exercise is comparing the autonomy you expect with the authority the agent can actually exercise. This will help guide your security conversations moving forward.

Since the CSA marked Level 3 as the place where things get interesting, let's take a closer look there. 

Imagine an infrastructure agent that is supposed to autonomously troubleshoot development environments while escalating anything involving production. On paper, that sounds like a Level 3 boundary. 

Now imagine the AWS credential available to the agent has permissions covering development and production. The agent's prompt may say not to touch production. Its operating policy may say not to touch production. The credential layer says production is available, and there is nothing stopping the agent from using it as a means to accomplish the goal.  Just ask the PoketOS team.

Those mismatches are what organizations need to find. A prompt instruction is a behavioral boundary. Credential scope is an access boundary. When the two disagree, the agent has more potential reach than the organization intended.

Why AI autonomy magnifies existing credential exposure

Useful AI agents are almost never deployed into completely clean environments with perfectly managed identities and narrowly scoped credentials.

They are entering enterprises already dealing with secrets sprawl.

GitGuardian detected 28.65 million new hardcoded secrets in public GitHub commits during 2025, up 34% year over year. Credentials tied to AI services reached more than 1.27 million, an 81% increase. In that same report, 24,008 unique secrets were found in public MCP configuration files, including 2,117 valid credentials.

AI agents are being added on top of this existing credential layer.

Agents inherit access from the environments where they run

Developer endpoints make the problem particularly visible.

A developer's laptop can contain cloud keys, .env files, SSH keys, shell history, package registry credentials, browser sessions, CLI caches, MCP configuration files, and agent transcripts. At the same time, agents are increasingly creating and writing credentials into local files without a human explicitly deciding where those secrets should live.

The developer's laptop is a credential store.

Alt: Secrets inventory on the laptop

An agent running there can inherit an enormous amount of potential reach simply because of where it operates.

More integrations quietly mean more autonomy

Agent ecosystems also encourage teams to keep connecting tools. MCP servers, plugins, APIs, CLIs, and integrations are what make an agent useful. Each integration usually needs some kind of authority.

The result is additive.

An agent that could originally edit code can now open tickets. Then it can access GitHub. Then the cloud. Then a database. Then an internal documentation system.

No single change necessarily feels like a major autonomy decision. The combined system may look very different six months later.

It is a self-perpetuating cycle, where more integrations create more credentials, and more credentials create more possible routes through the credential layer.

Agents can gain authority without gaining a new identity

The situation becomes harder to see when agents operate through existing credentials. An agent may inherit the developer's shell, use a service-account key created years ago, or authenticate with a personal token stored in a configuration file.

An organization may have good visibility into the nominal owner of the identity while having much less visibility into which human, script, agent, or MCP workflow is currently exercising its authority. This is a central challenge in AI agent identity.

As agents gain the ability to make more decisions independently, understanding these inherited access paths becomes part of understanding their real autonomy.

What good looks like: matching controls to the level you grant

Your immediate goal should be visibility. Start by inventorying the agents in use and understanding where they operate. Then map the tools and systems available to them.

From there, ask: What credentials are explicitly configured for the agent? What credentials exist on the machine or workload where it runs? Which are valid? Which are long-lived? Which grant access far beyond the agent's expected task?

Alt: GitGuardian incident exploration map showing how the secret is used

The most important comparison is between intended autonomy and available authority.

An agent designed for Level 1 behavior can still present substantial risk if every approved action executes with an administrator credential.

An agent you think is at CSA Level 3 may appear tightly bounded while carrying credentials that ignore those boundaries entirely.

The exercise therefore works in both directions. Start with the CSA framework to understand how independently the system can act. Then inspect its credential reach to understand the consequences of that independence.

That gives security and AI platform teams something concrete to investigate without forcing a prescriptive autonomy architecture onto every use case.

Where AI autonomy is heading

Agents will continue gaining tools, integrations, longer-running tasks, and deeper access to enterprise systems. Some of that autonomy will be intentional. Some will arrive as feature updates, new MCP connections, modified permissions, reused credentials, developer experiments, or agents created outside the formal AI program.

That second category should concern security teams most.

Autonomy can change after deployment. CSA even raises the question of dynamic classification because a single agent may operate at different levels depending on the capability or context involved.

The same agent might behave like Level 1 when deploying to production, Level 3 when modifying development systems, and effectively Level 0 when merely analyzing documentation.

Its access can change just as quickly. The agent you approved three days, or weeks, ago may have more tools today. The developer machine underneath it may contain new production credentials, or a new MCP server may have been connected. 

Understanding autonomy therefore cannot be a one-time review. Organizations need continuous, near real-time visibility into the credential layer beneath their AI systems.

3 steps to evaluate your AI autonomy use and mitigate credential risks

Every part of the modern enterprise depends on credentials to connect people, applications, infrastructure, and services. Those credentials cross team and department boundaries. Together they form a credential layer underneath the entire enterprise.

Agents increasingly operate across that same layer. If you want to know how autonomous an agent can become, start by understanding the authority available to it.

This is where GitGuardian's mission as the Credential Layer Security Platform directly intersects with AI autonomy.

Step #1: Detect the access agents already have

The first part of addressing your credential layer is detecting any and all credentials. Organizations need to see credentials across the entire credential-carrying surface, because that's ultimately what AI agents will access.

That includes source code and CI/CD systems, along with collaboration platforms, developer endpoints, AI agent directories, MCP configurations, local caches, secret managers, vaults, and the other places where credentials live or travel.

Teams need visibility into developer workstations. This is what GitGuardian delivers with Developer Endpoint Protection. It can discover plaintext credentials across local files, shell histories, config files, IDE caches, browser data, MCP configurations, and files created by AI coding agents. GitGuardian also inventories local AI agents and MCP servers, including what tools and data they can access.

That inventory begins to answer the autonomy question in concrete terms:

• Which agents exist?
• Where are they running?
• Which credentials are within reach?
• Which systems do those credentials unlock?

The answer can reveal an agent whose real access has grown far beyond the workflow anyone originally approved.

Alt: GitGuardian inventory view of NHIs and their secrets

Step #2: Remediate access that expands the agent's reach

Teams need to gather as much information as possible during the detection phase of any plan in order to remediate the situation. 

Not every secret presents the same danger. A test token used only in a dev environment and a valid production cloud credential should produce very different responses. GitGuardian can rank endpoint findings by severity and access scope and route them into existing security workflows.

No team has unlimited time or resources.  Every team needs to reduce the noise and focus on what areas carry the most risk. The goal of securing agent access is to address credentials that create dangerous access paths.

That can mean revoking a credential the agent no longer needs, rotating an exposed secret, reducing permissions, eliminating duplicates, or moving a plaintext credential into an appropriate secret manager or vault.

For AI autonomy, remediation has another important effect. It can bring the agent's actual reach back in line with the autonomy the organization intended to grant.

The infrastructure agent restricted to development should carry development-scoped authority. The coding agent working in one repository should not inherit access to every repository in the company.

Credential remediation turns those intended boundaries into real limits on what the agent can reach.

Step #3: Prevent autonomy from expanding through secrets sprawl

As teams work to rein in agents' access paths, they also need to prevent new credential exposure from quietly expanding agent access again.

This has to happen close to where agents work. GitGuardian AI hooks provide guardrails inside tools such as Claude Code, Cursor, and Copilot. They can prevent agents from reading, copying, or transmitting detected secrets across files, tool calls, and chats.

Developer Endpoint Protection also gives centralized visibility into credentials accumulating on local machines, while honeytokens can alert teams when credential-harvesting activity reaches an endpoint.

These controls address a fundamental problem with autonomy creep: Every new plaintext credential can become another access path, and every new access path can expand what an agent can reach. Every increase in reach can increase the autonomy that agent already has.

Understanding CSA levels gives organizations a useful language for recognizing how independently agents operate.

Understanding the credential layer shows organizations what those agents can actually affect.

Organizations need both views.

As agents become more autonomous, sometimes intentionally and sometimes simply through the accumulation of tools and access, security teams need to continuously understand those paths.

Detect the credentials within reach. Remediate the access that creates real danger. Prevent new plaintext credentials from expanding that reach further.

That is how organizations can understand the autonomy they already have and bring security to the credential layer underneath it. That is the mission of GitGuardian as a credential layer security platform.

Start gaining control of your agent autonomy today.