English 
A few years ago, identity security mostly meant protecting employees. Security teams worried about stolen passwords, phishing campaigns, and privileged user accounts. That model is rapidly becoming outdated. Modern enterprises now run thousands of automated processes, AI agents, APIs, serverless functions, and microservices that constantly talk to each other without a human ever touching the keyboard.
The problem is simple. Every one of those interactions requires trust.
According to Gartner’s 2026 IAM outlook, human and machine identities have now emerged as the primary attack surface. That is a major shift in how organizations should think about cybersecurity. The next generation of attacks will not always target employees. They will target the invisible digital workforce quietly operating behind the scenes.
こちらもお読みください： スキル・インテリジェンス・プラットフォーム日本におけるAIによる人員計画の再構築
As AI agents start making decisions, reaching into data, and kicking off autonomous workflows, protecting non-human identities isn’t just a ‘nice to have’ kind of security project anymore. It’s turning into the front line of enterprise defense, like, right now. And because of that change, teams have to rethink identity management, secrets protection, and access governance, from the very foundations up again.
What Are Machine Identities in the Era of AI?
Machine identity security is the practice of discovering, managing, authenticating, and protecting non-human digital identities that allow systems, applications, AI agents, APIs, and workloads to securely communicate with each other.
Traditional machine identities are not new. Servers, IoT devices, virtual machines, containers, and network appliances have been leaning on digital certificates, and cryptographic trust for years now. Things like X.509 certificates, OAuth tokens, API keys, and service accounts already make up the backbone of today’s cloud setup, sort of quietly all the time.
What’s changed is the rise of AI native workloads.
An AI app doesn’t just take a request and spit out a result. It may reach out to several APIs, spin up temporary sessions, touch vector databases a bit, work with outside tools, kick off serverless functions, and then coordinate across dozens of microservices in just a few seconds. And with each one of those exchanges you get yet another machine identity that has to be verified, authenticated, and governed properly.
This evolution is already visible across major cloud platforms. Google Cloud now treats AI agents as a dedicated Agent Identity, describing them as first-class principals, separate from human users or traditional service accounts. These identities are built on SPIFFE standards and cryptographically bound through unique X.509 certificates. It also mirrors a broader industry drift toward identity-first AI architectures.
In short, machine identities are no longer supporting infrastructure. They are becoming active participants in enterprise operations.
How AI Workloads Accelerate the Machine Identity Crisis
Traditional Identity and Access Management was built around predictable human behaviour. Employees log in, request access, complete a task, and log out. Even privileged users generally operate within observable patterns.
AI breaks that model.
Modern AI systems can autonomously launch workflows, create temporary API connections, retrieve information from multiple sources, and chain together dozens of actions without waiting for human approval. The speed alone creates a visibility problem that conventional IAM was never designed to solve.
アイビーエム highlights this difference clearly in its 2026 agentic AI research. The company notes that AI agents act autonomously, execute tasks, call external tools, and coordinate across systems with minimal human involvement. In many cases, a single user request can trigger dozens of independent machine actions within seconds.
That scale changes the security equation.
A developer may launch a proof-of-concept AI assistant that generates temporary credentials to connect with internal databases. Another team may build an automation pipeline using third-party APIs. A business unit may integrate an external LLM service into customer support operations.
Individually, each project seems manageable.
Together they end up generating thousands of machine identities, which are often just temporary, pretty decentralized, and kind of hidden from the security team in practice.
The hard part is not only about putting those identities in place. The real hard part is holding a steady line of sight into who actually spun them up, what exact capabilities they can use, how long they’re supposed to hang around, and whether they’re still warranted or needed at all.
Without that kind of oversight, AI workloads can gradually and, basically, widen an organizations attack surface faster than older governance approaches can even adjust.
The 3 Core Security Risks for AI-Driven Enterprises
1. Secret Sprawl in AI Pipelines
AI development moves fast, and security often struggles to keep pace.
Developers under pressure to build prototypes frequently hardcode API keys, database credentials, or access tokens directly into scripts and repositories. Experimental projects evolve into production systems, while forgotten credentials remain active long after their original purpose disappears.
In enterprise cloud assessments, one recurring pattern appears again and again. Orphaned API keys are often left behind after AI experiments, creating silent entry points that nobody actively monitors.
This is exactly why modern secrets management has become essential. AWS describes its Secrets Manager platform as a service built to manage, retrieve, and automatically rotate database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycle.
The underlying lesson is simple. Credentials should never become permanent artifacts embedded inside AI pipelines.
2. Excessive Entitlements and the Blast Radius Problem
Many organizations still grant AI agents broad read and write permissions because it is operationally easier than carefully defining access boundaries.
That convenience creates unnecessary risk.
An AI agent designed to summarize internal documents may receive unrestricted access to storage systems. Another may be allowed to query multiple databases simply because future functionality might require it.
This approach directly conflicts with the principle of least privilege.
The larger the permission set, the larger the blast radius when something goes wrong. A compromised machine identity with excessive entitlements can move across systems far faster than a traditional user account because automated workloads naturally operate at machine speed.
Access should be narrow, temporary, and continuously validated rather than permanently assigned.
3. Shadow Non-Human Identities
Shadow IT is not a new concept. Shadow machine identities are.
Modern development teams create service accounts, tokens, certificates, and AI agents independently across multiple cloud environments. Many of these identities are never formally registered, documented, or reviewed.
Over time, organizations lose track of what exists.
A forgotten service account from an abandoned AI pilot may still retain production access months later. A temporary OAuth token may remain active because nobody owns the decommissioning process.
These hidden identities become ideal targets because attackers rarely need to break security controls if they can simply inherit forgotten trust relationships.
Four Pillars of a Future-Proof Machine Identity Architecture
Continuous Discovery and Inventory
見えないものを守ることはできません。.
The first step is building a complete inventory of every machine identity across cloud environments, AI workloads, APIs, containers, and 自動化 platforms. Discovery cannot be treated as a quarterly exercise because AI environments change daily.
Visibility must become continuous.
Centralized Secrets Vaulting
Hardcoded credentials belong to an earlier era of application development.
Instead, organizations should move toward centralized vaulting systems that inject secrets dynamically when applications require them. This reduces credential exposure while giving security teams a single place to monitor access and enforce policy.
The goal is not simply storing secrets. It is controlling how they are issued, consumed, and retired.
Automated Lifecycle and Rotation
Many enterprises still track certificates and API keys through spreadsheets and manual processes. That approach does not scale in environments where AI workloads can create and destroy identities automatically.
Issuance, renewal, rotation, and revocation should all happen through automated workflows.
Short-lived credentials reduce the window of opportunity for attackers while removing much of the operational burden from security teams.
Machine identities should have lifecycles, not permanent existence.
Zero Trust for AI Agents
信頼ゼロ is often discussed in the context of human users, but its principles apply equally to machines.
Every machine-to-machine interaction should be authenticated, authorized, and continuously evaluated based on context.
An AI agent should never receive broad trust simply because it exists inside the corporate network. It should prove its identity, validate its permissions, and receive only the minimum access required for the specific task it is performing.
The future of machine identity security is not based on perimeter defense. It is based on continuous verification.
The CISO’s Actionable Checklist for Machine Identity Management
Strong strategy only matters if it turns into operational discipline. セキュリティ leaders should regularly validate that the following controls are already in place.
- Audit all AI workflows and development pipelines for hardcoded secrets and embedded API keys.
- Build and maintain a complete inventory of non-human identities across cloud and AI environments.
- Implement Just-in-Time access wherever machine identities require privileged operations.
- Establish a single source of truth for certificates, cryptographic keys, and service accounts.
- Automate credential issuance, rotation, and revocation instead of relying on manual tracking.
- Apply least-privilege access policies to AI agents and machine workloads.
- Reduce maximum token lifespans to limit attacker dwell time.
- Continuously monitor for orphaned machine identities created by experimental AI projects.
These actions may appear operational, but together they create the foundation for long-term resilience.
Fighting AI with AI in Identity Governance
The conversation around AI security often focuses on models, prompts, or data. In reality, identity may become the defining security challenge of the AI era.
Every autonomous workflow, every API call, and every AI agent ultimately depends on trust. The organizations that treat machine identities as background infrastructure will spend the next few years chasing an attack surface they cannot fully see.
Deloitte’s 2026 research found that only 21 percent of organizations have a mature governance model for agentic AI, while roughly 80 percent still lack mature governance capabilities. That gap is likely to become one of the biggest cybersecurity risks facing modern enterprises.
The next generation of identity governance can’t really run at a human pace, because AI doesn’t. In order to protect machine identities that think, act, and communicate on their own, enterprises will more and more need security systems powered by AI, able to track, confirm, and steer those identities in real time.
日本語