AI Agent Security Starts With Identity, but Enterprises Need More Than Credentials

Google News surfaced a September 2 warning about AI agents, but the conflict reaches far beyond another security checklist. The article argues that enterprises must answer three questions before agents spread further: Where are they, what can they connect to, and what can they do?

That framing appeared in a GuidePoint Security guest article by Ariel Zommer, an Okta security product marketer. Its central claim is simple. An agent becomes an identity problem once it can authenticate, reach corporate systems, or act without constant human direction.

The timing matters. NIST published a separate identity warning on August 27, less than one week before the GuidePoint article appeared. Microsoft, Okta, and other identity providers are also turning agent identities into formal product objects.

This convergence changes the enterprise debate. The central question is no longer whether a model can produce an accurate answer. It is whether every resulting action has a visible actor, limited authority, responsible owner, and revocable connection.

The argument sounds familiar because identity management already governs employees, applications, and traditional workloads. Agents complicate that model because their actions are probabilistic, their connections change, and one request can trigger many downstream operations.

Identity is therefore necessary, but it is not sufficient. A credential can identify an agent without proving that its current action is safe. The real contest is between accountable autonomy and convenient access that organizations cannot fully trace.

What Google News Actually Surfaced

The news is not a new vulnerability disclosure. It is a coordinated warning that agent adoption is outrunning enterprise identity controls.

The original identity argument was published by GuidePoint Security on September 2, 2026. It was written by an Okta employee and presented as a partner perspective.

That distinction matters. Readers should treat the article as vendor-backed analysis, not independent proof that one commercial platform solves every agent security problem. Its three questions remain useful because they describe measurable control gaps.

The first question asks where an organization’s agents exist. An inventory must include internally developed agents, features embedded inside SaaS products, cloud-hosted agents, employee-authorized tools, and experimental systems.

Traditional asset inventories often miss these categories. A developer can create an agent inside an approved cloud account without registering it as a separate business application. An employee can also authorize an outside tool through OAuth.

OAuth is an authorization standard that lets one application receive limited access to another service. Its convenience can hide persistent trust relationships from teams that never approved the underlying agent.

Discovery therefore requires more than scanning code repositories. Security teams also need cloud inventories, application registrations, OAuth grants, service accounts, browser signals, API gateway records, and Model Context Protocol connections.

Model Context Protocol, or MCP, lets AI applications connect with tools and data through a common interface. It can simplify integration while expanding the set of reachable systems.

The second question asks what each discovered agent can connect to. That map should cover business applications, internal APIs, databases, collaboration systems, secrets, service accounts, and other agents.

A connection does not reveal the complete risk. Security teams also need its authorization method, permission scope, credential lifetime, business owner, approval history, and revocation path.

The third question asks what an agent can do after connecting. Read access, record modification, code execution, money movement, and user impersonation carry very different consequences.

Those permissions can also combine. An agent that reads email and creates support tickets looks limited when each connection is reviewed separately. It becomes more consequential when it can extract instructions and trigger external actions.

Google News helped place the warning before a broader audience. However, the important event happened underneath the aggregation layer. Identity vendors and public standards bodies are converging on agents as first-class enterprise actors.

That shift gives security leaders a clearer starting point. It also creates pressure to distinguish an agent’s identity from the user, application, or service account that launched it.

A borrowed employee token cannot provide that distinction cleanly. Neither can one shared API key used by several agents. Both arrangements weaken attribution during audits and incident investigations.

The immediate change is conceptual but operational. Enterprises now need separate lifecycle records for agents, including creation, ownership, authorization, review, suspension, and retirement.

Identity Has Become the AI Control Plane

An agent needs a distinct identity because authority without attribution turns routine automation into an unbounded investigation problem.

Identity and access management, or IAM, determines who can access a resource and under which conditions. Existing IAM systems already provide directories, policy engines, access reviews, token services, and audit records.

Those components give enterprises a practical foundation. They can register an agent, associate it with an owner, grant specific permissions, and revoke those permissions when the agent changes or retires.

NIST reinforced this position in its recent identity foundation analysis. The agency warned that early deployments are prioritizing features and immediate value over established identity practices.

NIST also highlighted credential sharing as a core problem. Shared credentials undermine accountability because investigators cannot reliably determine which person, service, or agent performed a transaction.

The issue becomes sharper when agents delegate tasks. A user might ask one agent to prepare a sales briefing. That agent could call another system for account data and a third service for competitive research.

Every handoff creates an authorization decision. The enterprise must preserve the originating user, the acting agent, the requested resource, and the purpose behind the request.

Without that chain, logs can show that a service account accessed a database. They cannot explain which agent initiated the action, which user requested it, or whether the action matched an approved workflow.

A first-class identity can restore part of that context. Each agent receives a unique identifier instead of borrowing a general-purpose account. Policies can then target the specific agent.

That model supports least privilege, which limits an identity to the minimum access required for its assigned task. It also supports revocation without disrupting unrelated applications or employees.

Short-lived tokens strengthen the design. A token is a signed credential that represents granted authority for a limited scope and duration. Short expirations reduce the value of stolen credentials.

Federated credentials offer another improvement. They let a trusted workload request a token without storing a reusable secret inside code, configuration files, or an agent’s memory.

Ownership completes the basic record. Every production agent needs a named human or accountable team responsible for its purpose, permissions, reviews, and retirement.

The owner cannot merely be the developer who created the first prototype. Business ownership matters because someone must decide whether the agent’s access remains necessary.

Lifecycle status matters too. An experimental agent should not retain production permissions after a test ends. A replaced agent should not remain active because its API key still works.

This structure resembles governance for employees and applications. Yet agents require more frequent evaluation because their tools, instructions, models, and delegated tasks can change independently.

Enterprises should therefore treat the identity directory as a control plane, not a static address book. Registration starts governance, but continuous policy enforcement makes it meaningful.

That distinction also protects legitimate experimentation. Developers can receive a defined path for registering an agent instead of waiting for a large security review after deployment.

A usable registration process should capture purpose, owner, environment, tools, data classes, permissions, and expected operating boundaries. It should also assign an expiration or review date.

If the approved route is slower than creating an unregistered agent, teams will bypass it. The identity program must therefore make secure onboarding easier than hidden deployment.

This is where knowledge management practices can support governance. Teams need searchable records connecting decisions, owners, requirements, approvals, and later changes.

An inventory alone answers where an agent was registered. Connected operational knowledge explains why it exists and whether its present behavior still matches that purpose.

The Three Questions Expose Three Different Failures

Discovery, connection control, and action governance are separate disciplines, and passing one does not compensate for failing another.

“Where are my agents?” tests visibility. Security teams cannot govern an agent that appears only inside a developer’s account, an employee’s browser, or a SaaS administrator’s configuration.

A useful inventory must include sanctioned and unsanctioned deployments. It must also distinguish active agents from templates, abandoned experiments, disabled instances, and ordinary applications using AI features.

The inventory should identify every agent’s environment and operational state. Development, testing, and production agents should not share the same approval assumptions.

Security teams must also decide what counts as an agent. A chatbot that only returns text presents a different authority profile from a system that invokes tools or changes records.

The definition should focus on behavior. If software selects actions, calls connected tools, or delegates work with limited human review, it belongs in the governed population.

“What can they connect to?” tests the organization’s trust graph. A trust graph records relationships among identities, credentials, applications, resources, and delegated services.

That graph should show direct and indirect reach. An agent might lack database access but possess permission to call a service that can query the same database.

Agent-to-agent connections make the mapping harder. One agent can pass context or authority to another, creating a chain that crosses platforms and administrative boundaries.

Enterprises must record whether each connection uses standing access or task-specific authorization. Standing access remains available between tasks, increasing exposure if the agent is compromised.

Task-specific authorization grants narrower access for a defined operation. It can expire after completion and require new evaluation when the agent’s context changes.

“What can they do?” tests runtime control. The answer cannot be a list of API scopes copied from an application registration.

A scope might allow file modification, but policy should still distinguish routine editing from deleting a repository. The same technical permission can cover actions with different business consequences.

Runtime authorization evaluates a proposed action when it occurs. It can consider the acting agent, originating user, resource sensitivity, requested operation, location, and current risk signals.

Some decisions should remain automatic. Requiring human approval for every low-risk lookup would remove the productivity value that agents promise.

High-impact actions deserve stronger friction. Changes to production systems, transfers of money, disclosure of regulated information, and irreversible deletions need explicit safeguards.

Human-in-the-loop approval is one option. It places a person at a defined decision point before the agent completes a sensitive action.

Approval must provide meaningful context. A prompt that says “allow action” without naming the resource, data, purpose, and expected effect becomes a ceremonial checkbox.

Organizations also need reliable deactivation. A kill switch should revoke the agent’s active access across connected systems instead of disabling only its visible interface.

That capability depends on credential architecture. Central revocation works poorly when agents use scattered API keys, cached tokens, or credentials copied into outside services.

The three questions therefore form a sequence. Discovery establishes the subject, connection mapping defines potential reach, and action governance controls exercised authority.

Skipping the sequence creates false confidence. An organization can maintain a complete agent directory while leaving every listed agent over-permissioned.

It can also issue narrowly scoped tokens while missing employee-created agents. Alternatively, it can log agent actions without retaining enough identity context to attribute them.

The value of the framework lies in those failure boundaries. Each question gives auditors and security leaders a specific claim to test instead of a general assurance about “responsible AI.”

Identity Controls Cannot Decide Whether an Action Is Wise

A valid identity answers who is acting, but it does not guarantee that the agent understood the request or chose a safe action.

This limitation defines the article’s central tradeoff. Enterprises need identity-based controls, yet agents remain less predictable than traditional applications using the same credentials.

A conventional service executes code written for a known workflow. An agent can interpret instructions, select tools, generate parameters, and adjust its path based on returned information.

That flexibility creates value. It also means authentication success cannot serve as evidence that the next decision matches the user’s intent.

Prompt injection illustrates the gap. An agent can encounter malicious instructions inside a document, email, web page, or retrieved record and treat them as part of its task.

The attacker does not need to steal the agent’s identity. The attacker can try to manipulate a properly authenticated agent into misusing its legitimate permissions.

OWASP lists identity and privilege abuse among its agentic security risks. The category covers manipulation of delegation chains, inherited roles, cached credentials, and agent context.

Tool misuse creates another problem. An agent may call an approved tool with unsafe arguments or at the wrong stage of a workflow.

Identity controls can deny access to an unapproved tool. They cannot independently determine whether every permitted call supports the user’s actual goal.

Security architecture must therefore treat the model as an untrusted decision component. Deterministic controls should remain outside the model wherever consequences matter.

A deterministic control follows explicit rules rather than generating a probabilistic response. Examples include permission checks, schema validation, transaction limits, and mandatory approval gates.

The policy engine should evaluate what the agent proposes, not rely on the agent to police itself. The agent should not be able to rewrite the rules controlling its authority.

Input and output validation remain important. Tool parameters should conform to expected schemas, resource limits, data classifications, and approved destinations.

Network controls can reduce reach further. An agent that never needs public internet access should not receive it by default.

Data controls matter because identity does not prevent inappropriate disclosure to an approved recipient. Policies must also consider data sensitivity, purpose, and retention.

Monitoring must focus on behavior as well as sign-ins. Successful authentication followed by unusual enumeration, mass downloads, or repeated denied actions deserves investigation.

This is where the identity-first claim needs careful wording. Identity provides the anchor for accountability, revocation, and policy. It is not a complete agent safety system.

A commercial identity platform can centralize registration and tokens. It cannot guarantee that every connected model resists manipulation or interprets ambiguous goals correctly.

Vendor neutrality also remains uncertain. Agents will span Microsoft, Google Cloud, Amazon Web Services, Salesforce, ServiceNow, internal frameworks, and specialized SaaS products.

Each platform can represent agents differently. Cross-platform identity requires interoperable tokens, consistent claims, trusted issuers, and policies that survive handoffs.

MCP adds another boundary. An enterprise might govern the agent while depending on an external server to expose tools accurately and protect its own credentials.

An identity layer also needs protection from compromise. Centralized directories and token services become valuable targets because they can affect many agents at once.

Enterprises should separate administrative duties, protect high-privilege changes, and monitor unusual policy modifications. Agent governance cannot rest on one broadly privileged console account.

Audit logs deserve the same skepticism. A large volume of events does not automatically produce useful evidence.

Investigators need records that link the user request, agent identity, delegated agents, selected tool, authorization decision, affected resource, and final result.

Retention policies must preserve that chain long enough for investigations and regulatory reviews. Sensitive prompts and outputs may require minimization or restricted access.

The correct conclusion is narrower than the vendor message. Identity is the beginning of agent security because control needs a known subject.

Security still requires layered defenses around that subject. Those layers include constrained tools, external policies, protected credentials, data controls, monitoring, and human review.

Microsoft and Okta Are Turning the Model Into Products

The identity-first idea is moving from conference language into directories, token flows, discovery systems, and revocation controls.

Microsoft Entra Agent ID illustrates how a major platform now represents agents directly. Microsoft describes an agent identity as a specialized service principal with a unique identifier.

A service principal represents an application or workload inside an identity tenant. The agent version lets policies and logs distinguish the agent from its underlying blueprint.

Microsoft’s autonomous authentication flow separates an agent identity from reusable production secrets. The documentation recommends managed identities or certificates instead of client secrets.

Autonomous agents can request application tokens for their own identity. Interactive agents can use delegated flows when acting for an authenticated user.

That difference is essential. An autonomous nightly reporting agent should not appear identical to an assistant performing one action for a signed-in employee.

On-behalf-of authorization preserves the user relationship during delegation. The resulting token can identify the user as the subject and the agent as the actor.

This design gives resource servers more context for authorization. A system can ask whether that user, acting through that agent, may perform the requested operation.

Microsoft also documents special agent user accounts for resources that require user-like objects. Such accounts can support mailboxes or collaborative features without using normal human credentials.

Those accounts include restrictions. Microsoft says they cannot receive privileged administrator roles, creating a boundary against some forms of escalation.

Okta is pursuing the same market from a platform-neutral identity position. Its April agent identity launch described discovery, registration, managed connections, governance, and deactivation.

The company says its directory can import agents from external platforms and register custom agents. It also describes detection of shadow agents through OAuth consent signals.

Okta frames its product around the same three questions repeated in the GuidePoint guest article. That overlap confirms the article’s commercial context.

The product message deserves scrutiny, but the implementation categories are concrete. Enterprises need directories for agents, narrow tokens for connections, and policy enforcement for actions.

Competition should benefit buyers if platforms expose interoperable controls. Microsoft’s model can fit organizations centered on Entra and Microsoft Graph.

Okta emphasizes governance across multiple clouds, applications, and agent frameworks. Cloud providers will naturally integrate their agent services with their existing workload identity systems.

The danger is fragmentation. An enterprise could end up with one agent inventory per cloud, another inside its identity provider, and several inside SaaS administration portals.

Those inventories will disagree unless the organization defines a canonical ownership and lifecycle process. Discovery tools should feed that process rather than create parallel sources of truth.

Token compatibility is another issue. OAuth can standardize authorization mechanics, but vendors may differ in identity claims, delegation evidence, and runtime policy controls.

Agent-to-agent communication raises the stakes. The first agent might carry a user’s delegated authority, while a downstream agent operates autonomously under application permissions.

The authorization chain must show where authority changed. Otherwise, an approved user request can become a broad machine action without visible escalation.

Procurement teams should test products against real workflows. A polished directory interface matters less than whether the platform can revoke access across every affected connector.

They should also test exportability. Audit data must remain accessible for incident response, compliance, and migration without depending on one proprietary investigation view.

Security teams should avoid granting a new agent platform unrestricted access simply to improve visibility. Discovery architecture needs its own least-privilege review.

The market is therefore moving toward identity as shared infrastructure. The winners will not merely register agents.

They will preserve attribution across platforms, reduce standing credentials, support granular revocation, and expose policy decisions in records that outside tools can evaluate.

What Enterprises Should Verify Before Scaling Agents

The next stage will be measured by deployment evidence, not by how many vendors repeat the phrase “first-class identity.”

The first signal is whether enterprises build complete inventories that include shadow agents. A directory populated only through formal onboarding will miss the riskiest deployments.

Organizations should compare identity records with OAuth grants, cloud resources, browser telemetry, API usage, and SaaS configurations. Large gaps would weaken the identity-first promise.

The second signal is whether short-lived, scoped authorization replaces static secrets. Migration counts matter more than a platform’s ability to issue modern tokens for new agents.

Teams should identify existing agents using embedded API keys, shared service accounts, and long-lived refresh tokens. They should then measure how quickly those credentials disappear.

Microsoft’s documentation gives enterprises one technical reference point. Its production guidance favors federated credentials and managed identities over stored client secrets.

The third signal is whether runtime controls survive cross-platform delegation. This will determine whether agent identity becomes genuine infrastructure or another isolated product category.

A useful test begins with one human request that triggers several agents and tools. Investigators should reconstruct the complete chain without correlating unrelated logs manually.

The record should identify the originating person, every participating agent, each token exchange, the policy applied, and every affected resource.

Revocation should work across the same chain. Disabling the initiating agent must not leave delegated credentials or downstream sessions active.

Enterprises should also run adversarial tests. A red team can place malicious instructions inside content that an authorized agent is expected to retrieve.

The test should reveal whether external policy blocks dangerous actions after the model accepts the instructions. Identity alone will not produce that result.

Business leaders need a decision framework for acceptable autonomy. Not every agent requires identical review because consequences vary widely.

A research assistant that reads public documents carries different risks from an agent that edits production code. An accounts-payable agent introduces another category entirely.

Access reviews should reflect those differences. High-impact agents need shorter certification cycles, tighter limits, stronger monitoring, and defined human approval points.

Incident response plans must include agents as actors. Teams should know how to suspend an identity, invalidate tokens, isolate connectors, preserve logs, and identify affected data.

The plan should cover compromised third-party agents too. Pre-granted OAuth trust can remain dangerous even when the enterprise’s internal code was never breached.

Security teams should ask vendors how quickly they disclose connector compromises and revoke issued access. Contract language should address logs, notification, and investigation support.

Developers need clearer standards at design time. Every new agent should declare its owner, tools, data classes, authorization pattern, and maximum permitted consequence.

That information can become part of an internal AI workflow record. Product, security, and engineering teams can then review changes against the original purpose.

The Google News item offers a useful checkpoint, but repetition should not be mistaken for resolution. Identity providers have defined the problem more clearly than enterprises have implemented the answer.

The three questions create a practical first review. Can your organization name every agent? Can it map every reachable system? Can it constrain and reconstruct every material action?

A “yes” needs evidence from directories, tokens, policies, and logs. A spreadsheet maintained for an audit does not prove runtime control.

Start with one production workflow and trace it from human intent to final effect. Remove shared credentials, narrow every connection, and define where automatic action must stop.

Then test revocation and reconstruction under pressure. If either fails, the agent has more autonomy than the organization can safely explain.

Google News will move to another headline. The identity gap will remain until enterprises can connect every agent action to limited authority, clear ownership, and enforceable policy.