Modern infrastructure is increasingly run by automated systems, not people. Bots push code. Runners deploy to prod. Agents orchestrate cloud resources. And increasingly, AI models trigger actions directly through prompt-driven automation.
Welcome to the era of non-human identities (NHIs): the invisible workforce operating behind modern digital systems.
But here’s the catch: while human users authenticate with SSO and MFA, most NHIs still access critical resources with static credentials, excessive permissions, and minimal oversight. This creates both a security risk and a threat to infrastructure resiliency.
Teleport Machine & Workload Identity was built to bring order, trust, and traceability to non-human access, replacing static secrets with short-lived, cryptographic identity to enable secure, scalable automation.
Below, we’ll step through four common use cases that demonstrate how our customers are using Teleport to regain visibility and control over NHIs.
1. Securing CI/CD pipelines
CI/CD pipelines are fast and repeatable, but often operate with more trust than is warranted. Automation tools like GitHub Actions, Jenkins, or GitLab runners access cloud resources, push containers, run migrations, and deploy infrastructure. But under the hood, most still rely on hardcoded secrets: long-lived tokens, shared SSH keys, or environment variables that are rarely rotated.
Teleport issues short-lived certificates to non-human identities like CI/CD runners and bots. These credentials expire automatically and are tightly scoped to each job, enabling secure CI/CD automation. Static credentials like API tokens or SSH keys are eliminated completely, NHI access is tightly scoped and time-bound, and all machine-to-machine activity is logged for full auditability.
Example
Deploying a container to Kubernetes from GitHub Actions without storing any kubeconfigs or cloud credentials:
Enroll the GitHub Actions runner as a trusted workload in Teleport with a just-in-time identity token from a GitHub App integration
The runner starts a job and uses tbot (Machine & Workload Identity agent) to fetch a short-lived x.509 + SSH identity, issued based on workload identity instead of a stored secret
tbot writes short-lived credentials (e.g., kubeconfig, AWS creds, SSH certs) to a secure local directory, which are valid for 20 minutes
The workflow uses the issued kubeconfig to deploy the container to Kubernetes
No long-lived secrets were stored in GitHub, passed between systems, or rotated manually, ensuring the complete workflow is ephemeral, auditable, and identity-based
2. Infrastructure-as-Code (IaC) deployment
When deploying infrastructure with tools like Terraform, Pulumi, or CloudFormation, automation manages critical assets like VPCs, clusters, databases, and secrets. But many IaC workflows use cloud service accounts with broad permissions, or rely on injected environment secrets to execute tasks.
Teleport’s Machine & Workload Identity model issues ephemeral, per-job certificates tied to cryptographic identity, not secrets. This makes it easy to enforce least privilege per repository, deployment, and environment.
Example
Terraform deploying to AWS from GitHub Actions, without long-lived IAM keys:
On job start, the runner uses tbot to fetch a short-lived identity with an AWS role assumption policy
tbot writes AWS credentials valid for 15–20 minutes, scoped to exactly one role
The AWS role is assumed via Teleport’s AWS integration with least privilege per workload, and based on workload identity and Teleport roles instead of per repo or team
3. Federated identity across multi-cloud environments
NHIs often require access across AWS, GCP, Azure, and edge environments. But each provider has its own identity system, making federation complex and error-prone.
Teleport acts as a unified identity authority for machines and workloads. This reduces the complexity of cloud federation by issuing standard cryptographic identities (e.g., x.509 certificates with SPIFFE ID) to NHIs across all environments.
The result is uniform workload authentication across clouds and platforms without shared credentials or tokens. Access governance across cloud environments is simplified through consolidated identity policies, reducing the risk of misconfigurations.
Example
A GCP workload needs access to an AWS resource:
A GKE workload runs a sidecar with Teleport’s Machine & Workload Identity agent
At startup, the agent authenticates with Teleport and receives
A x.509 certificate with SPIFFE ID: spiffe://yourorg/workload/payment-processor
The workload uses this cert* to:
Call an AWS API via mTLS (proxying through Teleport), and to authenticate to AWS STS using AssumeRoleWithWebIdentity
All logs, trust policies, and expirations are managed centrally by Teleport
*Note: Certs are not single purpose. If the workload in this example also needed to communicate to a database, the same credential could be used as a multi-purpose identity
4. Securing Model Context Protocol (MCP)
The Model Context Protocol (MCP) defines how LLMs securely access infrastructure context and tooling. But without strong identity and access controls, MCP-enabled systems can expose secrets, perform unauthorized actions, or be abused through prompt injection.
Teleport brings trust to MCP environments by issuing short-lived, cryptographic identities to AI agents and model contexts, ensuring that every AI action is authenticated, scoped, and auditable. Zero trust principles are applied to every query or interaction, full traceability from LLM prompt to action is maintained, and safe boundaries for prompt-driven automation are established.
Example
A developer uses an internal LLM agent (via MCP) to query system logs and restart Kubernetes pods:
Without Teleport
With Teleport
The agent uses a shared API key with admin permissions
When the LLM is instantiated, it requests a short-lived identity from Teleport scoped to read-logs and restart-pod operations
There is no visibility into which action was triggered by which prompt
These actions are authorized using Teleport’s RBAC policies, tied to the AI agent’s assigned role
If the key is leaked, any attacker can restart services
Each action (e.g.,kubectl delete pod) is executed using mTLS over a secured channel, and logged with the agent’s workload identity
Bring trust to NHI and infrastructure everywhere
Teleport Machine & Workload Identity is built to solve the challenges of non-human identities within modern infrastructure.
By unifying access control and replacing static credentials with short-lived, cryptographic identity, Teleport enables secure automation across CI/CD pipelines, infrastructure provisioning, multi-cloud federation, and platform operations.
Engineers move faster, infrastructure resiliency grows stronger, and non-human identities are efficiently managed and secured.
State of MCP Server Security 2025: 5,200 Servers, Credential Risks, and an Open-Source Fix – Astrix Security
This blog post shares the findings from the Astrix Research team’s large-scale “State of MCP Server Security 2025” research project. We analyzed over 5,200 unique, open-source Model Context Protocol (MCP) server implementations to understand how they manage credentials and what this means for the security of the growing AI agent ecosystem.
The research findings were eye-opening: the vast majority of servers (88%) require credentials, but over half (53%) rely on insecure, long-lived static secrets, such as API keys and Personal Access Tokens (PATs). Meanwhile, modern and secure authentication methods, such as OAuth, are lagging in adoption at just 8.5%, confirming a major security risk across the ecosystem. To provide an immediate solution to this foundational problem, Astrix is releasing the MCP Secret Wrapper, a new open-source tool. This tool wraps around any MCP server to pull secrets directly from a secure vault at runtime, ensuring that no sensitive secrets are exposed on host machines.
Unpacking the State of MCP Security Research 2025: The Full Story
The AI agent era is here, powered by the Model Context Protocol (MCP). When the MCP specification was first released, the Astrix Research team, like many, saw its immense potential. We also saw a potential blind spot. While the protocol empowers servers to make API requests, the initial examples relied on a dangerously insecure foundation: the use of hardcoded, overly permissive, and non-expiring credentials, such as classic Personal Access Tokens (PATs) or API keys. We feared this was creating a crack in the foundation of the new AI-powered world.
Months later, our initial fears have proven to be more than justified. With unofficial registries (e.g., mcp.so) indexing over 16,000 MCP servers, it’s clear the ecosystem is vast and sprawling. But its scale also reveals a deeper problem: the foundational approach to identities is broken, creating systemic risk regardless of how the ecosystem is organized. To understand the true scale of this risk, the Astrix Research team launched a large-scale “State of MCP Server Security 2025” research project. We analyzed over 5,000 unique open-source MCP server implementations to answer a set of fundamental questions:
How are these MCP servers really managing credentials?
What is the true prevalence of high-risk static secrets versus modern secure protocols?
What does this mean for the security of the enterprises that rely on them?
Key Findings from the MCP Server Security Research.
Approximately 88% of servers require credentials.
Over half (53%) rely on static API keys or Personal Access Tokens (PATs), which are long-lived and rarely rotated.
Only 8.5% use OAuth, the modern, preferred method for secure delegation.
79% of API keys are passed via simple environment variables.
A total of 20,000 MCP server implementations on GitHub
That is why, alongside this research, Astrix is releasing MCP Secret Wrapper, a new open-source tool designed to eliminate this foundational security flaw. Below, we share our full findings and methodology. It is a data-driven look into the secrets of MCP —a story of explosive growth and security implications.
Why Examine Credential Management in Model Context Protocol Servers?
The origin
In November of last year, Anthropic released the Model Context Protocol, a new method for augmenting AI assistants with the ability to fetch data and take actions. Effectively, this capability transforms AI assistants into full-fledged agents. When the protocol specification dropped, the Astrix research team immediately began inspecting it.
One of our first questions was: if MCP Servers are responsible for making API requests, where are the credentials stored? The initial specification didn’t mention this at all. What about the identities these servers need?
To our concern, almost all initial sample servers released to showcase MCP’s capabilities relied on the simplest, most broadly-permissive, never-expiring, worst type of NHIs:
GitHub supporting classic PATs
GitLab supporting PATs
Postgres access with basic username and password
Back then, MCP was just another initiative. We were excited about its capabilities but worried about the identities servers would use. We figured that by the time the framework was fully adopted and running, the identity perspective would mature significantly.
Back to the present
This brings us to the present. While the official examples were corrected, the pattern they established had already taken hold.
The MCP framework has become a central topic in AI and a main driver of AI Agent adoption, and thousands of developers, following those initial patterns, have built and published their own servers. Organizations are rapidly adopting MCP servers to stay current. Besides the official launch of the MCP Server registry, unofficial marketplaces have indexed upwards of 17,000 servers!
Yet, with the expansion of the MCP ecosystem, the vast majority of the MCP servers still followed the original, insecure methods for handling identity.
Naturally, we wondered if our initial fears had materialized. Every good research begins with asking questions, and here were ours:
How many real open-source MCP Server implementations exist? (GitHub is riddled with forks and example/tutorial servers). How close is the indexed number to the real count?
How many servers need an identity or credentials to operate? (Some MCP Servers operate locally and use the user’s own security context such as filesystem, playwright, and more)
What types of NHIs are servers using? What credentials enable authentication?
How are credentials provided to the server? (Hard-coded, configuration files, environment variables, etc.)
Are tools easily separated into sensitive and non-sensitive categories? (Read and write operations, for instance).
Research Findings
Finding 1: Estimating the True Number of MCP Servers
First, let’s talk about the number of real servers we managed to find. Our hunch proved somewhat correct, with a 30% drop between the total number of repositories downloaded and those implementing real MCP Servers.
Based on our analysis (see Appendix 1), we estimate that there are a total of 20,000 repositories in GitHub implementing MCP servers. This puts the amount of servers we collected at ~19% of total implementations. This ensures deviation in our analysis is relatively small (also leaning into the side of caution, given that we downloaded highly-starred repositories) and instills confidence that our results closely reflect reality.
Finding 2: 88% of MCP Servers Require Credentials
As shown on the chart above, a high percentage of servers mentioned credentials (88%!) This finding provided an indicator of a trend: credential usage is the norm for MCP servers, pointing to a broad reliance on accessing protected data and services.
However, this binary outcome (using a credential or not) is most likely to be inaccurately judged by the LLM, even at a large scale. The credential type analysis (where the analyzer had to categorize credentials into specific buckets) paints a slightly different picture.
The crux of our research – what types of NHIs do MCP Servers use? We allowed the analyzer to categorize credentials into 4 buckets:
API Key
Typically a single string providing direct API access, generated without direct relation to an identity.
Access Tokens (ATs) and Personal Access Tokens (PATs)
Tokens usually provided to users for API queries, scoped to their access. Very common in code repositories like GitHub and GitLab.
OAuth
While not every downstream platform supports OAuth, it’s considered best practice. It allows users to delegate access to the MCP Server while creating a dedicated NHI (usually as a new app with a client identifier). Servers implementing OAuth must be mature, as they might need to manage different tokens for different users, considering AI Agents utilizing MCP can serve multiple users simultaneously.
Unknown
So the analyzer isn’t forced to choose from the above.
And the results… 🥁
A total of ~53% of servers utilize static credentials: API keys and access tokens. This means these credentials are long-lived, rarely rotated, and stored in configuration and .env files across multiple systems today, confirming a major security risk!
Meanwhile, only ~8.5% of servers use OAuth. While adoption is growing, it’s still far behind, despite being the best approach for security.
Finally, 26.4% of servers landed in the “Unknown” bucket while still mentioning credentials. This can’t solely be explained by servers that don’t actually require credentials but mention them in passing in their README.md. It points to potential difficulty for the LLM-based analyzer to correctly predict credential types.
Finding 4: 79% of MCP Servers Store API Keys in Environment Variables
What about credential storage methods? The LLM-based analyzer struggled to understand specific storage types – configuration files usually mean credentials are passed into environment variables and can be provided that way, making it difficult to infer possible methods. However, binary analysis proved semi-successful, indicating whether servers only expect credentials via environment variables or configuration files, or support more advanced methods.
The analysis above pertains only to API Keys, with a significant portion (79%) of MCP Servers simply obtaining them from environment variables.
Unfortunately, this question proved too advanced for the LLM-based analyzer to answer concretely. Defining what constitutes a sensitive tool isn’t easy – while we focused on the API call made at the end and whether it accesses or acts on sensitive resources, this isn’t easily identified by examining tool definitions.
Defining whether a tool is sensitive (e.g., performs write vs. read operations) is not easily identified by examining tool definitions in a README file. We believe definitive answers require code-level analysis and leave this for future research.
(If you take this on, let us know! We’d be very interested in the results and happy to update this section with a reference).
What Can Be Done? Enter: Astrix’s MCP Secret Wrapper
Given the findings in our State of MCP Server Security 2025 research, the path forward is clear. MCP Servers must use NHIs to access protected enterprise resources, and we showed that implementations today overwhelmingly rely on coarse, long-lived secrets exposed statically in configuration files.
So, really, what can you do about it? Well, today, you can do something!
Today, Astrix is releasing the MCP Secret Wrapper, an open-source project that smartly and simply wraps around any MCP server. Instead of relying on static credentials in configuration files, it pulls the relevant secret from a vault (currently, the project supports AWS Secrets Manager) and starts the designated MCP server with the secret injected into its environment variables. Utilizing this tool ensures no exposed secrets exist on any machine hosting MCP servers.
Removing static credentials is just one piece of the puzzle – it doesn’t address the issue of secrets being coarse or their longevity. However, you can apply auto-rotation policies to vaulted secrets.
Since the secret is pulled dynamically, the MCP server remains completely unaffected and continues operating happily. Of course, rotation isn’t simple, and this is where Astrix can help!
Astrix’s Agent Control Plane (ACP) is the industry’s first solution designed to deploy secure-by-design AI agents across the enterprise. With ACP, every AI agent receives short-lived, precisely scoped credentials and just-in-time access, based on least privilege principles, which eliminates access chaos and reduces compliance risk.
Research Methodology
Identifying Real MCP Server Implementations
Indexing and searching through billions of code repositories is a monumental feat. If you’ve ever tried GitHub’s code search, you know how extensive yet quick it is – supporting even complicated regex while returning thousands of results in seconds.
However, the API-based search is different. It only supports the legacy code search mode, and for repositories, it can only search through their owner, name, description, and README.md file. It has very restrictive rate limits, but the real difficulty is that it only returns the first 1,000 results per search query.
We wanted to search for MCP Server implementations. There’s no simple tag or common convention to match against. Given the search API’s limitations, we had to think creatively. Here are the techniques we used:
Adding boolean constraints to narrow down results, such as specific programming languages with MCP SDK support: language:Python, language:TypeScript
Searching for very specific strings – like matching the (relatively long and distinct) configuration file for Claude desktop: claude_desktop_config.json
Per programming language with MCP SDK support – matching library imports or usage patterns: using ModelContextProtocol.Server for C#
Ordering results by star count. This ensures the top 1,000 results are more likely to be actual MCP Server implementations
By combining these techniques, we successfully extracted real MCP Server implementations, detecting 5,205 distinct GitHub repositories and downloading their README.md files.
Analyzing README.md files
Analyzing thousands of different README.md files required an efficient, scalable approach. We were confident these files contained the answers to our research questions, as they usually include enough information to determine:
Whether the repository implements a real MCP Server
The tools made available by the server
The expected identity and credentials used by the server
Where credentials should be placed and how they’re provided to the server
But README.md files are written for humans, not code. Thankfully, we live in the AI era, so our task was to write an effective prompt and use an LLM for the large-scale analysis.
We instructed the AI to detect whether the README.md belongs to a real MCP Server implementation (as opposed to a sample server, fork, etc.), identify what types of credentials are used (from a predefined set), how the server consumes credentials, main features offered, types of tools used, and finally, provide a confidence score for the analysis.
Appendix
Analyzing Total MCP Server Count Under GitHub API Limitation
Since GitHub search queries return the total number of results (even though only 1,000 are available), we estimated approximately 50,000 implementations related to MCP on GitHub. Taking the 30% drop at face value would mean 35,000 MCP Servers exist today.
However, we believe the number is significantly lower. We observed a 30% drop, but our data was skewed toward highly starred repositories, which are more likely to be legitimate. (If sampled randomly, you’d expect many more repositories with fewer than 10 stars)
To accurately predict the number of MCP Server implementations, we’d need to sample randomly from the 50,000. However, GitHub doesn’t offer an “order by randomness” feature. If we had to estimate, approximately 20,000 MCP Server implementations exist, making third-party MCP Server registries quite close to indexing every possible server!
Astrix was one of the earliest companies offering an NHI security platform. They can be credited as the first to coin the term “Non-Human Identity,” going back to the RSA Innovation Sandbox competition in May 2023. Coining the term “NHI” came after a number of positioning iterations, such as 3rd-party integration access controls and App-to-App security (not to be confused with SaaS-to-SaaS) as Astrix began its journey all the way back in 2021 with a focus on core environments spanning across IaaS, PaaS and SaaS.
The company quickly recognized the importance of behavior anomaly detection for the usage of these identities. One of the core competencies of Astrix is having years of training on real world API traffic to detect anomalies in near-real time. The same engine that actually detected a 0-day vulnerability in Google GCP back in 2022, more on that later.
The platform’s key capabilities include:
NHI Discovery and Inventory: Identifying and cataloging NHIs across various environments like AWS, Github, Slack, and Active Directory.
Posture Management: Ensuring NHIs adhere to least-privilege principles and are properly configured to minimize attack surfaces.
Lifecycle Management: Orchestrating the lifecycle of NHIs, including secret rotation, NHI retirement, and reassignment.
Anomaly Detection and Threat Remediation: Analyzing NHIs for unusual behavior or configuration anomalies and remediating issues directly in workflows
A few notable elements of their platform’s capabilities include:
Behavioural analysis: They have an AI-based threat engine that detects abuse of NHIs based on anomaly indicators such as unusual IP, user agent, and activity.
Vendor supply chain attacks: They map every associated NHI, allowing a company to see everything an NHI is connected to in their tech stack and what it’s used for, so in the case of an incident involving a third party, a company can either rotate or remove an NHI quickly. Since they comply with SEC disclosure guidelines, they can expedite incident response when a company’s external vendor is compromised.
Policy deviations: They prevent NHI abuse by enforcing organizational policies on NHIs. They use existing tools to mitigate policy deviations such as access from forbidden geos, number of API calls and more. Beyond Astrix’ strong NHITDR play, their aim is to secure these identities across different environments, particularly SaaS, on-prem and cloud-native environments, which form the backbone of most modern enterprises. Astrix’s platform focuses on managing the lifecycle and security posture of non-human identities.
A key component of Astrix’s solution is its risk engine. This engine assesses the risk level of every NHI by analyzing its permissions, potential for compromise, and how it interacts with external suppliers or internal systems. This allows Astrix’s customers to prioritize the most critical threats and take action on high-risk NHIs. Customers can use Astrix’s remediation workflows to fix issues such as over-permissioned accounts or compromised secrets.
The company has a broad platform, but its strengths relative to competitors lies with its ability to detect cross-environment threats, built-in remediation engine and real-time threat detection . While Astrix is primarily cloud-native, the company is actively developing capabilities to manage NHIs within on-prem environments. Key on-prem focus areas include Active Directory service accounts and on-prem databases, as well as SaaS tools deployed on-prem, such as GitHub Enterprise. Astrix is applying the lessons learned from cloud environments to ensure that on-prem NHIs are managed with the same level of sophistication.
Astrix Security manages the human-user lifecycle and its intersection with non-human identities (NHIs) by providing a seamless approach of tying human users to the NHIs they create and manage. This critical feature ensures that each NHI, such as service accounts or API keys, is associated with an accountable owner, allowing organizations to track and manage these identities throughout their lifecycle. For instance, when a human user is off-boarded, Astrix’s platform ensures that any associated NHIs are also revoked or retired, preventing security gaps caused by lingering, unmanaged identities. Additionally, during access reviews, the platform helps ensure that both human-user access and the permissions granted to NHIs are evaluated together, reducing the risk of orphaned or overly privileged NHIs. This owner assignment mechanism offers an additional layer of security, enabling organizations to quickly identify and remediate issues by knowing exactly which user is responsible for each NHI. This capability is foundational to Astrix’s strategy of providing comprehensive lifecycle management and ensuring security across all identity types.
Another strength of the Astrix platform is the Astrix research group, which specializes in NHI behaviors, risks, and vulnerabilities. These insights enrich the platform continuously. The Astrix research group is famous for the discovery of the Ghost token zero-day in GCP, which was actually patched by Google.
Astrix provides a unified platform that addresses NHIs by offering extensive coverage across multiple environments, including cloud-native, and SaaS. This approach is vital for enterprises with complex, hybrid infrastructures that require consistent NHI visibility and control across different layers of their stack. Astrix’s ability to monitor and secure AWS, CICD tools, SaaS platforms, and on-prem solutions like Active Directory gives it a significant advantage, providing customers with a holistic view of their NHI ecosystem.
At the core of Astrix’s offering is its powerful risk engine, specifically designed to assess the risk levels of NHIs. The risk engine evaluates the permissions, configurations, and usage of each NHI. It assigns risk scores based on these factors, helping organizations prioritize threats and focus remediation efforts on the most critical NHIs. The company’s deep understanding of how NHIs function within SaaS platforms allows it to offer more targeted and effective security solutions for enterprises that rely heavily on tools like Slack, AWS, and other SaaS applications. Astrix partnered with the Cloud Security Alliance to survey over 800+ security leaders, the report unveils the state of Non-Human Identity Security – from top challenges and risks to tooling, programs, and budget allocation – The State of Non-Human Identity Security. I highly recommend checking it out.
Astrix’s Agent Control Plane (ACP): Secure AI Agents from Day One – Astrix Security
AI agents are transforming work at machine speed, but most still rely on wide-open, never-expiring credentials that can slip them into places they don’t belong—often without anyone noticing until it’s too late.
Astrix’s Agent Control Plane (ACP) changes that. From day one, every agent gets just-in-time access, Zero Trust guardrails, and full auditability, so enterprises can scale AI fast without scaling the chaos.
In this blog post, we will dive into why traditional tools can’t keep up with AI agents and how ACP enables rapid adoption without compromising security.
Security blind spots at machine speed
Welcome to the new reality of enterprise AI, where autonomous agents are busy transforming how we work, but also creating major security gaps we’re only beginning to understand.
Every AI agent in your organization is essentially a highly privileged employee who never sleeps, never takes breaks, and operates with credentials that often have more access than your C-suite. Is it enough to keep most security leaders up at night?
The real kicker? Most organizations are still managing AI agent access the same way they did for applications built in 2010, using service accounts and other “forever” keys.
Why traditional security can’t keep up with AI agents
Think of AI agents like incredibly efficient interns who were given the master key to your office on their first day. They need to:
Access customer databases to answer queries
Connect to code repositories to deploy updates
Interface with dozens of other 3rd-party applications to do their jobs
Traditional identity and access management (IAM) treats these agents like any other application, issuing long-lived API keys, service accounts, and OAuth tokens that essentially become permanent backstage passes to your entire digital infrastructure.
The perfect storm of risk factors
The credential time bombMost AI agents operate with credentials that never expire. It’s like giving someone a keycard to your building and never checking if they still work there, except this “someone” is running 24/7 across multiple systems.
The visibility voidWhen an AI agent accesses 15 different systems in 30 seconds, can your security team tell you exactly what it touched and why? For most organizations, the answer is a resounding no.
The compliance nightmareTry explaining to auditors how your AI agents, which can autonomously make decisions affecting customer data, fit into your existing compliance framework. Watch their expressions change from confusion to concern.
Enter the Agent Control Plane: Security that moves at AI speed
This is where Astrix’s Agent Control Plane (ACP) fundamentally changes the game. Instead of retrofitting yesterday’s identity security onto tomorrow’s AI, ACP provides purpose-built identity management for the age of autonomous agents.
How ACP works: Security by design, not by accident
Imagine if every AI agent in your organization operated like a visitor in a high-security building:
They receive a temporary badge (short-lived credentials) that only works for specific floors (resources)
Their access expires automatically after completing their task
Every door they open is logged in real-time
Security can revoke their badge instantly if something looks suspicious
That’s essentially what ACP does, but at machine speed and scale.
The three pillars of secure AI agent management
Just-in-time access: The end of forever credentials
Traditional approach: Give your AI agent a permanent key to the kingdom and hope for the best.
ACP approach: Issue credentials that last only as long as needed – minutes or hours, not months or years. When the job’s done, access disappears. No cleanup required, no forgotten credentials lying around like digital landmines.
Policy at creation: building security into AI DNA
Instead of deploying agents first and adding security later (spoiler: “later” often means “after an incident”), ACP enforces least-privilege policies from the moment an agent comes online.
Rather than letting a new employee wander the building and then deciding which rooms they shouldn’t enter, you program their keycard with exactly the right permissions before they walk through the front door.
Continuous compliance: Keeping agents on track
ACP doesn’t just set policies and forget them. It continuously monitors agent behavior, flagging anomalies before they become incidents.
It’s the difference between:
Old wayDiscovering during an annual audit that an agent had unnecessary access for 11 months
ACP wayGetting an alert the moment an agent deviates from its approved access pattern
From chaos to control: What changes with ACP
For security teams: Visibility meets velocity
Security teams gain a unified control plane that shows:
Every AI agent in the organization
Exactly what each agent can access
Real-time activity monitoring
Instant revocation capabilities
No more spreadsheets. No more guessing. No more hoping you’ve found all the agents before the auditors do.
For development teams: Speed without sacrifice
Developers can deploy AI agents through simple API or CLI integration. No security bottlenecks, no weeks-long approval processes. Pre-approved access patterns mean that compliant agents get instant credentials, while non-compliant requests get flagged immediately.
The result? AI innovation continues at full speed, but within guardrails that prevent costly mistakes.
For the C-suite: AI as accelerant, not liability
When AI is a board-level mandate (and in 2025, it almost always is), executives need confidence that their AI investments won’t become tomorrow’s headlines. ACP transforms secure access from a checkbox exercise into visible business velocity with metrics that matter:
Time from AI agent conception to secure deployment: Days, not months
Compliance audit preparation time: Hours, not weeks
Mean time to detect and respond to agent anomalies: Minutes, not days
Discover, secure, and deploy with Astrix
ACP is the “Deploy” piece of Astrix’s broader Discover–Secure–Deploy framework, which delivers the industry’s first complete solution for enterprise AI agent security.
With Astrix, organizations can discover every agent and its credentials, secure them with least-privilege policies and real-time monitoring, and now deploy them safely with ACP’s Zero Trust guardrails, just-in-time credentials, and built-in audit trails.
It’s security that moves at the speed of AI, because anything slower simply won’t cut it anymore.
Ready to take control?
The age of AI agents is here. The question isn’t whether you’ll deploy them, it’s whether you’ll deploy them securely from day one.
See ACP in action: Schedule a demo to discover how leading enterprises are securing their AI agents with Astrix.
SailPoint brings true identity governance to non-human identities. Founded in 2005, SailPoint delivers innovative solutions that address some of the world’s most dynamic security challenges. Our passion for solving our customers’ identity and security needs continues to guide us today.
Why SailPoint Many tools treat machine accounts like human ones—ignoring the unique lifecycle, risk profile, and scale of non-human identities. SailPoint delivers a dedicated solution for machines, built into our unified identity platform. That means one place to govern all identities—human, machine, third-party, and AI agents—together.
SailPoint Machine Identity Security Overview
Get a breakdown of core features, key benefits, and how SailPoint’s Machine Identity Security helps you discover, govern, and secure non-human access.
Demystifying Machine Identity: A Three-Part Exploration
Start with the basics—what a machine identity is and why it matters—then dive deeper with articles on its historical evolution and where traditional security practices fall short. This series unpacks the complexities and stakes of governing machine identities today.
Part 1 – What is a machine identity? Understanding the foundations of digital existence
Part 2 – The evolution of identity: From seals to systems
Part 3 – Beyond security basics: How traditional best practices have failed machine identity
Learn how this key feature of SailPoint’s Machine Identity Security solution uses intelligent pattern recognition and system scans to uncover hidden, misclassified, and orphaned machine accounts. See how it drives visibility, reduces manual effort, and strengthens audit readiness—kickstarting machine identity governance.
Artificial intelligence is no longer a future concept; it’s a present-day reality in the workplace. Companies are rapidly adopting AI agents—autonomous systems designed to achieve specific goals—to drive efficiency and innovation. But while the business world embraces AI for its undeniable benefits, a new global survey reveals a hidden and rapidly growing security crisis simmering just beneath the surface.
The people closest to technology are sounding the alarm. According to the “AI agents: The new attack surface” report, an overwhelming 96% of technology professionals identify AI agents as a growing security threat, and a full 66% believe this risk is immediate. These findings, drawn from a global survey of hundreds of IT and security professionals, paint a stark picture of a technology being deployed faster than it can be controlled.
This report reveals four critical truths about the state of AI in the enterprise today. These takeaways highlight a clear and present danger that demands immediate attention from IT leaders, executives, and security professionals alike.
1. Your AI Is Already Performing Unintended and Dangerous Actions
The most shocking finding from the research is that AI security incidents are not a theoretical risk; they are an active, ongoing problem. A full 80% of organizations report that their AI agents have already performed actions that were beyond their intended scope, operating with a level of autonomy that exposes companies to severe vulnerabilities.
The report catalogs a series of alarming rogue behaviors that are already happening:
• Accessing unauthorized systems (39%)
• Accessing inappropriate or sensitive data (33%)
• Inappropriately sharing sensitive data (31%)
• Being coaxed into revealing access credentials (23%)
• Ordering things or getting phished (16%)
These statistics are not hypothetical scenarios or future possibilities. They are security breaches actively happening right now in four out of five companies using this technology, confirming that the AI in the office has already started going rogue.
2. There’s a Massive Gap Between Knowing the Risk and Managing It
The report uncovers a significant and troubling contradiction. On one hand, awareness of the threat is incredibly high: an overwhelming 92% of technology professionals agree that governing AI agents is critical to enterprise security.
On the other hand, action is lagging dangerously behind. Despite this near-unanimous agreement, only 44% of their organizations have actually implemented any policies to manage their AI agents. This “knowing-doing gap” is the equivalent of recognizing the fire alarm is ringing but having more than half the building’s occupants refuse to evacuate. This inaction leaves vast quantities of critical corporate data exposed, including customer data, financial records, intellectual property, and legal documents.
3. AI Agents Pose a Greater Risk Than Human Employees
Counterintuitively, technology professionals now view AI agents as a greater security risk than both machine identities (72% agree) and traditional human employees. This elevated threat level stems from a unique combination of broad access and minimal oversight that breaks traditional security models.
Compared to their human counterparts, AI agents are considered a super-risk for several reasons:
• They require much broader access to different systems and datasets to perform their tasks (54%).
• A single agent often requires multiple identities to function (64%), exponentially increasing management complexity.
• They are significantly harder to govern due to their potential for unpredictable behavior (40%).
• Their access is provisioned much faster and with less oversight, typically approved only by IT (35%).
This combination of expansive privileges provisioned solely by IT creates a scenario where no single person has the full picture, making it nearly impossible for security teams to apply the principle of least privilege, a cornerstone of modern cybersecurity.
4. Key Executives and Legal Teams Have No Idea What Data AI Is Accessing
This lack of governance is a symptom of a dysfunctional security culture, where technical awareness fails to translate into executive action. Perhaps the most dangerous finding is the critical information silo that exists within companies. While 71% of IT teams have been advised on the data their AI agents can access, this awareness plummets for the very stakeholders responsible for managing corporate risk: Compliance (47%), Legal (39%), and, most alarmingly, Executives (34%).
This profound visibility gap means that only 52% of companies can track and audit the data their AI agents use. This leaves a staggering 48% of organizations operating with a complete blind spot, unable to prove compliance or investigate a data breach effectively. This isn’t just flying blind; it’s handing the controls to a pilot who has never seen a map of the airspace and hoping for the best.
Conclusion: The Risk Is Accelerating
The findings from this report are a clear warning, yet the trend is only accelerating. Despite the documented risks of rogue actions, governance gaps, and executive blind spots, a staggering 98% of companies plan to deploy even more AI agents within the next 12 months.
As organizations push forward, they must recognize that an unmanaged AI is not just a tool, but a potential vector for catastrophic data breaches. The report’s conclusion puts it best: an unmanaged AI agent represents an even greater vulnerability, capable of compromising enterprise security with a single response to a cleverly crafted question.
As AI becomes an inescapable part of our daily work, the question is no longer if we need to govern it, but how quickly we can start. Does your organization truly know what its AI is doing?
Identity security as a business enabler: Protect more, do more, risk less – SailPoint
For many organizations, identity security is still viewed through a narrow lens, something that keeps the auditors happy, checks a compliance box, and helps avoid worst-case scenarios. While those outcomes are critical, that’s only part of the picture. Today’s most forward-thinking enterprises are starting to realize that identity security isn’t just about protection; it’s about enabling the business to move faster, with less risk.
At SailPoint, we believe identity security is a strategic advantage. When done right, it strengthens your security posture and drives agility, efficiency, and innovation across the enterprise. In short, identity security empowers you to protect more, do more, and risk less—all at once.
The challenge: More access, more complexity, more risk
Every enterprise is navigating a growing sea of identities and access points.
The addition of every new employee, contractor, AI agent, and machine identity presents risks – along with opportunities to create value for the business.
But with that expansion comes more exposure.
The old way of managing identities—manual processes, spreadsheets, siloed tools—can’t keep up. IT teams are overwhelmed, business users are frustrated, and leaders are left without visibility into who has access to what, and why.
This complexity leads to a dangerous choice: slow down the business to maintain control or move quickly and accept higher risk. Neither is acceptable or sustainable.
The opportunity: Identity as a strategic accelerator
This is where identity security changes the game.
With intelligent, automated identity security, organizations can eliminate that trade-off. You gain visibility and control over access, with the speed and flexibility needed to support business innovation.
SailPoint Identity Security Cloud is the solution purpose built to meet this moment. Our solution brings together AI, machine learning, automation, and deep identity intelligence to help enterprises manage and secure every identity, at every stage of their lifecycle.
With SailPoint, identity security shifts from being reactive and restrictive to being proactive, intelligent, and empowering.
Three ways identity security enables the business
1. Protect more: Prevent risk before it happens
Security is still the foundation, but with SailPoint, it’s no longer a static defense. Our solution uses AI and machine learning to proactively detect and prevent risk while addressing key identity security use cases as well as advanced capabilities needed in today’s transformative IT environments.
Instead of relying on human guesswork, you get intelligent AI-driven access recommendations, policy violation alerts, and continuous monitoring that adapts to your environment. Outlier detection highlights unusual access patterns before they become threats, while automated certifications ensure the right people retain the right access — continuously, not just quarterly. Capabilities like SailPoint Machine Identity Security and Non-Employee Risk Management address securing some of the fastest growing identity types in the dynamic digital landscape.
The result? Stronger security with far less effort—and fewer surprises.
2. Do more: accelerate access and innovation
Security shouldn’t be a bottleneck. With SailPoint Identity Security Cloud, it isn’t.
Automated provisioning means new hires, contractors, and third-party partners get access to what they need — immediately and accurately. No more waiting on IT tickets or manual approvals.
For business users, intuitive self-service access requests let them move faster, while built-in governance ensures decisions align with policy and risk thresholds. It’s freedom with control.
And for IT teams? Hours of manual work are eliminated, freeing up resources to focus on high-value initiatives.
This is how identity becomes a catalyst for productivity across the organization.
3. Risk less: Achieve compliance without the chaos
In highly regulated industries, compliance isn’t optional — but it doesn’t have to be painful. SailPoint simplifies identity audits and policy enforcement through automated, auditable processes at scale.
You get centralized visibility into access across systems, cloud environments, and user types, backed by identity intelligence that makes reporting fast and accurate. When auditors come knocking, you’re ready in minutes, not weeks.
More importantly, these controls aren’t just for show. They help you build real resilience into your operations, without slowing the business down.
Real-world impact: Identity security in action
This isn’t just theory, it’s real, and it’s happening across industries.
One SailPoint customer, a Fortune 100 pharmaceutical company, significantly increased operational efficiencies. They reported spending 40% less time on access reviews, completed 90% of reviews in the first 2-3 days of certification campaign launch, and realized a 30% reduction of manual tasks performed by IT.
These are more than security wins. They’re business wins, proof that when identity security is done right, it creates tangible, enterprise-wide value.
The takeaway: From reactive to strategic
The enterprise is evolving fast. Digital transformation, hybrid work, AI adoption, and growing regulatory demands are forcing organizations to rethink how they manage identity and access. Staying secure and compliant is no longer enough, you need to do so in a way that supports speed, scale, and innovation.
With SailPoint Identity Security Cloud, you don’t have to choose between protection and progress. You can deploy an identity security solution that was engineered to help you move up the maturity curve as your program evolves and grows, without costly and time-consuming re-architecting.
Identity security becomes a foundation for growth, giving you the confidence to move faster, act smarter, and operate with less risk.
Ready to protect more, do more, and risk less?
SailPoint Identity Security Cloud is designed for enterprises ready to modernize their identity program. Explore how we can help you automate, secure, and scale your identity strategy without compromise.
To learn more about SailPoint Identity Security Cloud and trends in the market, check out this webinar.
AI agents are here. Your identity strategy isn’t ready – SailPoint
AI agents don’t behave like humans. They don’t behave like machines. They’re something entirely new, and that’s exactly the problem.
These autonomous, goal-seeking entities are capable of reasoning, deciding, and acting on their own. They spin up in minutes, operate 24/7, and make millions of decisions per hour. With access to sensitive systems and data, they don’t follow predefined workflows or wait for human direction. They execute. Relentlessly.
While human identities are onboarded through HR systems and machines follow structured, predictable rules, AI agents operate with human-level intelligence at machine speed. They don’t show up in your HRIS. They’re not provisioned through traditional IT channels. And yet, they are rapidly multiplying across enterprise environments, often without anyone noticing.
This shift is creating a crisis of speed and scale in identity governance and security.
Traditional identity playbooks are breaking
Identity programs were designed around two fundamental models: human users and machine accounts. Both come with clear ownership, predictable behavior patterns, and lifecycle hooks for onboarding, offboarding, and access management.
AI agents don’t fit these models. They’re ephemeral, dynamic, and self-directed. They use OAuth tokens and SSO credentials, bypass traditional provisioning processes, and often act outside established governance frameworks. They’re already operating in your environment: connecting to APIs, ingesting data, and making decisions with far-reaching consequences.
Manual oversight doesn’t scale here. Static roles and infrequent access reviews won’t keep up. And the further enterprises lean into AI, through copilots, assistants, and intelligent automation, the wider this visibility gap grows.
A new identity model for autonomous agents
Two central security and governance problems have emerged in my conversations with business leaders: How do you ensure that agents are bound by the same entitlements as the humans they represent, and how do you ensure that humans don’t get access to more data than they are permitted through the agents they are accessing?
To solve these problems and secure AI agents more broadly, we need to redefine what governance looks like. That starts by treating these agents as first-class identities—just like humans and machines—but governed according to their unique behaviors and risks.
Here’s what that requires our industry to work towards:
Governing the entire access chain. You can’t secure what you can’t see. You need visibility into the non-deterministic agent access pathways: Human User/Owner –> Agent -> Machine -> App -> Data -> Cloud resources, or different combinations of this chain.
Real-time policy engines. Organizations need continuous visibility into every agent in their environment: what it’s doing, where it’s operating, and what it can access, to be able to enforce policies in real-time.
Short-lived credentials and dynamic scoping. Agents must operate with the least privilege possible. That means short-lived, narrowly scoped credentials that expire quickly and don’t grant persistent access.
Just-in-time, context-aware access controls. Access should be granted only when needed, and only if contextual signals (like location, workload, or user approval) support it.
Continuous, behavioral monitoring at machine speed. Governance doesn’t stop at access control. Continuous, real-time monitoring is essential to detect anomalous behavior and stop agents that go off-script before they cause harm.
Assigned accountability. Every AI agent should have a designated human owner responsible for reviewing its activity, governing its access, and decommissioning it when it’s no longer needed.
Ask the hard questions
Despite the growing adoption of AI agents, most organizations still can’t answer some of the most basic questions, like:
How many AI agents are operating in your environment right now?
What systems do they have access to?
Who is responsible for managing them?
Can you stop them if they begin to behave unexpectedly?
If your identity strategy doesn’t account for AI agents, the answer to most of these questions is likely “no.”
The agent economy has arrived
This isn’t a future problem. Thousands of AI agents are already active in enterprise environments, deployed by business units, third-party platforms, and external vendors. Some are governed. Most are not.
If you can’t govern it, you can’t secure it.
At SailPoint, we believe AI agents must be brought into the fold of identity security: monitored, controlled, and governed with the same rigor as any other identity. But doing so requires a shift from manual oversight to intelligent automation. From static controls to real-time enforcement. From old playbooks to new models.
The agent economy is already here. Now it’s up to identity leaders to catch up.
In today’s complex enterprises, identity security has become the cornerstone of a sound cybersecurity strategy. As organizations scale across cloud platforms and hybrid work models, managing who has access to what—and ensuring that access is appropriate—has never been more critical. Our latest insights reveal how artificial intelligence (AI) and machine learning (ML) are revolutionizing identity security through smarter, adaptive access and proactive risk detection.
Why identity security needs a makeover
Modern enterprises are juggling tens of thousands, if not millions, of digital identities—employees, contractors, partners, machine identities, AI agents, and more. Granting access while preventing unauthorized intrusion is a balancing act, especially when relying on manual processes and spreadsheets. These outdated methods leave gaps ripe for exploitation, from insider threats to external breaches.
SailPoint has employed AI and ML technologies in our solutions since 2017 to help inform, scale, and automate human decision-making, a natural fit for challenges in the identity security space. By automating identity tasks and providing insights into access behaviors, AI helps organizations stay secure, compliant, and efficient—without the human bottlenecks.
Access Modeling: Essential to efficient distribution of access
One of the key building blocks of a strong identity program is a well-structured access model. Traditionally, building and maintaining roles has been a painstaking process prone to role sprawl—the proliferation of unnecessary or overlapping roles that dilute security. SailPoint Access Modeling automates this through machine learning insights, grouping users by access patterns and generating dynamic role recommendations.
The platform’s Role Discovery capability can analyze access behaviors across departments to suggest accurate, ready-to-use roles. This not only speeds up onboarding but ensures that users get the access they need—no more, no less.
At SailPoint’s Navigate conference last year, we introduced a next-gen concept: Dynamic Access Roles. Unlike static roles that assign identical access to every member, dynamic roles adjust based on contextual attributes like job title or geographic location. For instance, if you have 500 store managers across 3 levels of seniority, you no longer need 1,500 roles to account for them. One dynamic access role can do it all.
This shift drastically reduces administrative and maintenance overhead, eliminates over-provisioning, and keeps your access model lean and responsive to change.
Smarter decisions with AI-powered recommendations
Even with a streamlined role model, the day-to-day operations of access governance can overwhelm security teams. That’s where SailPoint’s access recommendations step in:
Access request recommendations: Using peer group analysis and collaborative filtering, the system recommends whether access should be approved or denied. Low-risk access can even be auto-approved, freeing up time for high-priority reviews.
Access certification recommendations: During access reviews, SailPoint Identity Security Cloud suggests which access rights to certify or revoke. The system compares users with their peers and highlights deviations, reducing the risk of rubber-stamping, improving certification quality, and improving audit accuracy.
These features not only improve decision-making but also reduce fatigue and improve operational efficiency.
Spot the outliers before they become threats
One of the standout capabilities is SailPoint Identity Outliers. Identity outliers are identities that don’t conform to typical access patterns—either because of unusual entitlements or anomalous access. ML algorithms flag these outliers for review, allowing identity teams to swiftly investigate and remediate risks before they escalate.
Outliers can be an indicator of risky access or in some cases an indication of a set of unique roles or job function within the enterprise. Either way, early detection is critical, and AI makes it possible at scale.
Building a resilient, AI-first identity program
What ties all these capabilities together is the clear need for a cohesive, automated identity program. SailPoint’s AI and ML solutions help enterprises move from reactive identity management to proactive identity security. From modeling roles to recommending access decisions to spotting access anomalies, AI enables faster, more confident decisions with fewer resources.
With continually evolving security pressures and an expanding digital footprint, organizations can no longer afford to secure and govern access manually. AI is not just a nice-to-have; it’s a critical element of a robust identity security program.
Take the next step
Ready to evolve your identity security strategy? Download our latest whitepaper for a more in-depth look at how AI and ML identity security capabilities can help you build a successful identity security program.
In an era where identity is the new perimeter, leveraging AI is no longer optional—it’s the key to smarter, safer, and more agile security.
Human Error Is Inevitable — So Why Are Access Reviews Still Built Around It? – Clarity Security
There’s a hard truth that too few teams talk about: even your best people make mistakes when you ask them to do the same thing over and over again. That’s not an opinion — it’s human nature. And when it comes to access reviews or security, that nature becomes a liability.
Manual Review Leads to Error. Every Time.
In theory, User Access Reviews (UARs) are a vital security and compliance control: regularly confirming that people have the right level of access, and nothing more. In reality, they’ve become one of the most error-prone, resource-draining processes in identity governance. Not because your team isn’t capable, because we’re asking humans to behave like machines.
Reviewing 1 user’s access? Simple. Reviewing 10 users? Still manageable. Reviewing 1,000 users? That’s where things fall apart. Decision fatigue sets in. Entitlement names blur together. Context is lost. And people start approving access they shouldn’t — or overlooking what they don’t understand. That’s not failure of diligence. It’s a predictable outcome of a broken process.
The Cost of Human Error is Risk.
The downstream effects of mistakes in UARs are often invisible — until they’re not:
Lingering access after role changes or departures
Over-permissioned accounts with lateral movement potential
Missed separation of duties conflicts
Audit failures due to lack of documentation or rationale
When those errors add up, the result is more than inefficiency — it’s a weakened security posture and increased exposure to both breach and compliance risk.
Reducing Error Without Sacrificing Control
Clarity’s access review platform was designed with a simple goal: take repetitive, error-prone work out of human hands — and give people the context and tools they need to make smart, fast decisions.
Not all access deserves equal scrutiny. We elevate the riskiest entitlements and identities so they’re reviewed first — or more often. Prioritization based on risk.
Role-based access controls allow governance teams to focus in on “exceptional” access, that not everyone has access to and is inherently more risky. No more repetitive “yes you can have an email inbox” approvals in your reviews.
We surface data reviewers usually have to hunt for: who has access, when it was granted, whether it’s being used, and how it aligns with their role. This includes nested access.
Low-risk, low-change accounts? Bulk-approve them with confidence. Entitlements that haven’t been used in 90 days? Flag them for review or auto-revoke.
Every decision is logged with rationale, timestamps, and outcomes. When audit time comes, your documentation is already done.
10 Minutes, Zero Guesswork
With Clarity, most access reviews take under 10 minutes — and far fewer decisions are made under stress, in bulk, or without the data to back them up. Because a fast process isn’t just about speed. It’s about reducing the window for human error — and eliminating the hidden risk that creeps in when reviews are rushed, repetitive, or manually tracked.
Access reviews fail when they rely too heavily on human consistency. Clarity succeeds because it understands how people really work — and builds guardrails, automation, and intelligence around the places human error tends to sneak in. If your current process depends on perfect manual execution, it’s not a control — it’s a gamble.
