AI Agents Need Identity Before They Need a Gateway

Hush Security reached Google News with a sharp claim: enterprises need to identify each AI agent before putting a gateway around its traffic. The conflict matters because many agents still borrow human permissions or share credentials. A gateway can inspect connections, but it cannot establish accountability when every caller looks the same.

The argument followed Hush Security’s July 2026 funding announcement and the expansion of its non-human identity platform. The company raised $30 million and introduced an Identity Gateway designed to discover agents, assign identities, broker limited access, and record their actions. Its central idea is simple: security controls cannot govern an agent reliably until they know which agent is acting.

That position challenges a gateway-first approach emerging across enterprise AI. Cisco, Palo Alto Networks, Microsoft, and other security vendors now place controls between agents and tools. Yet a gateway sees requests, not necessarily the complete identity, owner, delegated authority, or execution history behind them. The result is a familiar security boundary with an unfamiliar attribution problem.

This is not a debate about whether gateways matter. They remain useful enforcement points for authentication, policy checks, traffic inspection, and tool restrictions. The question is whether enterprises are installing the checkpoint before issuing distinct credentials to everyone passing through it.

The Google News Headline Points to a Bigger Identity Shift

Hush Security is reframing AI agent security as an identity problem that gateways alone cannot solve.

The company emerged from stealth in 2025 with a focus on non-human identities. These include service accounts, API keys, access tokens, and other credentials used by software instead of employees. Hush initially addressed a long-standing enterprise problem: organizations often accumulate machine credentials that are difficult to inventory, rotate, and revoke.

Autonomous agents increase the stakes. They can interpret instructions, select tools, retrieve data, and take actions across several systems during one task. A conventional automation follows a predetermined sequence. An agent can alter its path after receiving new information, which makes its effective permissions harder to predict.

In its July 30 report, VentureBeat described how Hush was extending that earlier work into an agent identity gateway. The proposed platform sits between agents and enterprise resources. Hush says it can discover agents, connect them to human owners, issue task-specific access, log activity, and revoke an agent centrally.

Hush calls its access model “least agency.” The term adapts the security principle of least privilege, which gives a user or workload only the access required for a task. Least agency adds the agent’s objective, execution context, and delegated authority to that decision.

Consider a coding agent asked to diagnose a production error. It might need read access to logs, source code, and deployment metadata. It should not automatically receive permission to change billing records, download customer databases, or rewrite its own security policy.

The same distinction applies to productivity agents. An assistant preparing a meeting brief might search calendars, notes, and approved documents. It does not need unrestricted access to every mailbox, cloud drive, or administrative console available to the employee who launched it.

A gateway can block prohibited destinations or malformed requests. However, its policies become blunt when several agents use the same OAuth token or service account. It may know that an approved credential requested a file. It may not know which agent made the request, why it acted, or whether that action remained inside the original delegation.

This is why the Google News headline carries more weight than a typical funding story. Hush is not merely adding another inspection layer. It is arguing that identity must become the organizing record for an agent’s owner, purpose, permissions, sessions, and actions.

That model also changes incident response. Security teams usually begin an investigation by asking who accessed a resource. Shared credentials can reduce the answer to an application, employee, or service account. A distinct agent identity offers a narrower starting point, especially when several autonomous processes operate under one person’s authority.

Shared Credentials Leave Gateways Guessing

A gateway can enforce policy only as precisely as the identity and context attached to each request.

Many early enterprise agents were deployed like scripts. Developers stored an API key, assigned a service account, or passed through the human user’s OAuth token. That approach gets a prototype working quickly, but it collapses several actors into one security identity.

The employee, agent host, model, individual agent, and tool session can all appear under the same authorization. If the agent creates subagents, the chain becomes even harder to reconstruct. A downstream service might receive a valid token without knowing which component initiated the action.

VentureBeat’s June 2026 survey of 107 enterprise respondents found that 69 percent used shared API keys in agent deployments. Its agent security research also found that 82 percent relied primarily on controls supplied by model providers or hyperscalers.

Those controls provide useful protections. Prompt filters can detect known injection patterns, data-loss prevention systems can flag sensitive content, and cloud policies can restrict access to managed resources. None of those features automatically creates a distinct identity for every agent instance.

The survey found Microsoft Entra Agent ID at 13 percent adoption among respondents. Other identity-specific products appeared in the single digits. That gap suggests enterprises have deployed general AI protections faster than agent-specific accountability.

The imbalance becomes more serious when an agent receives excessive authority. A shared administrator credential does not become safe because a gateway monitors it. If the policy allows the credential to perform an action, the gateway may approve a dangerous request that is technically valid.

Prompt injection illustrates the problem. An agent might read untrusted text that tells it to retrieve confidential material or alter a configuration. The instruction can enter through a document, website, email, tool response, or database record. A language filter then faces the difficult task of distinguishing legitimate intent from manipulated intent.

Identity controls address a different layer. They do not need to determine whether every sentence is malicious. They can limit the maximum authority available to the agent, regardless of what the model decides.

For example, a research agent with read-only access cannot delete a source repository after encountering a hostile instruction. A temporary support agent cannot retain customer-data access after its ticket closes. A finance agent authorized to draft a payment cannot also approve that payment unless policy grants both actions.

Short-lived credentials further reduce exposure. Instead of placing a reusable secret inside an agent environment, an identity system can issue a token for one task, resource, and time window. The token expires automatically and can be revoked when the session ends.

This model also supports better logs. An audit record should identify the agent, its human sponsor, the task, the policy decision, the credential used, and the resulting action. Logging only the gateway request leaves investigators to infer too much after an incident.

Enterprises already preserve context when managing important human activity. They record the user, device, application, session, authentication method, and resource. Autonomous software needs at least comparable detail because it can execute many actions without pausing for human review.

The challenge is volume. An organization can create, copy, or terminate agents faster than it hires employees. Identity provisioning must therefore become automatic. Manual registration would create delays, encourage workarounds, and leave shadow agents outside governance.

That pressure makes lifecycle management essential. Each agent identity needs a creation event, owner, approved purpose, policy set, expiration rule, and revocation path. If any part remains undefined, the gateway receives traffic from an actor that the organization cannot fully explain.

A Gateway Controls Traffic, but Identity Establishes Authority

The strongest architecture treats identity as the source of authority and the gateway as one place where that authority is enforced.

An AI gateway usually mediates communication between models, agents, tools, and data services. It can authenticate connections, inspect requests, apply rate limits, filter content, and generate logs. An MCP gateway performs similar work for Model Context Protocol connections.

MCP is an open protocol that lets AI applications discover and call external tools through a common interface. It reduces the need for custom integration code, but standardized connections can also expand an agent’s reachable surface.

A gateway becomes useful because it provides a central policy checkpoint. Security teams can place rules in front of many tools instead of modifying each backend. That architectural convenience does not answer who the agent is or where its authority originated.

Identity supplies that foundation. A distinct identity can bind the agent to its code, host, owner, task, and approved capabilities. Authorization can then decide what that identity may do under current conditions.

The distinction resembles an airport checkpoint. Screening every traveler is valuable, but the process depends on knowing which traveler presents each document. Inspecting luggage without establishing identity produces an incomplete security record.

The US National Institute of Standards and Technology placed the same components in a broader framework during 2026. Its agent identity project identified agent identification, authorization, delegation, logging, transparency, and data provenance as connected areas of work.

NIST also pointed to established technologies rather than proposing one proprietary answer. OAuth can carry delegated authorization, OpenID Connect can express authentication information, and SCIM can support identity provisioning. SPIFFE and SPIRE can issue cryptographically verifiable identities to software workloads.

These technologies solve different parts of the problem. OAuth says what access a token conveys. OpenID Connect helps describe an authenticated party. SCIM can create or deactivate identity records. SPIFFE can attest that a workload running in controlled infrastructure is the workload it claims to be.

None independently captures the full life of an autonomous agent. An enterprise still needs to connect a workload identity with human delegation, policy, task scope, and action history.

That missing connection explains why simply assigning an agent a name is insufficient. A self-declared identifier inside a request can be changed or copied. A trustworthy identity must be issued or verified by a system that the receiving service accepts.

The identity must also survive movement across infrastructure. Agents can run in desktop applications, cloud containers, developer environments, managed platforms, and third-party services. A credential rooted only in one cluster may lose meaning when an agent crosses an organizational boundary.

An OpenID Foundation paper on agent identity management describes this portability challenge. It notes that an MCP client identifier is not necessarily a reliable workload or agent identity. It also explains how infrastructure-based attestation becomes harder when agents cross trust domains.

This issue separates authentication from agency. Authentication establishes that a software component controls a credential. Agency describes why that component acts, for whom it acts, and what delegation it currently holds.

A gateway needs both kinds of information. It should reject an unverified caller, but it should also reject a verified agent that exceeds its delegated task. Passing authentication cannot become permission to perform every action available to the sponsoring user.

Hush’s approach places policy-driven identity brokering before resource access. The gateway then becomes an enforcement mechanism for that brokered authority. This sequence supports narrower permissions and clearer attribution than a gateway that first discovers identity from traffic.

The architecture still depends on integration. Applications and tool servers must honor the identity claims, scopes, or capability tokens they receive. If downstream systems collapse every request into one privileged backend account, the identity record loses enforcement value.

Security Vendors Are Converging on the Same Control Point

The market is moving toward agent identity, but vendors differ on whether identity, network traffic, or endpoint behavior should lead enforcement.

Hush is not alone in treating agents as a new class of non-human actor. Microsoft, Cisco, Palo Alto Networks, 1Password, Okta, Ping Identity, and several startups have introduced agent-focused identity or governance features.

Cisco’s Duo Agentic Identity registers agents as distinct objects associated with human owners. Its broader security architecture can route tool calls through an MCP gateway. Palo Alto Networks has presented an agent registry, an identity provider for agents, and gateway controls inside Prisma AIRS.

Microsoft distributes agent governance across Entra, Purview, Defender, and Sentinel. Entra Agent ID focuses on creating and governing identities for agents. Other Microsoft services address data controls, threat detection, and monitoring.

CrowdStrike emphasizes endpoint activity. That approach tracks what software processes do on a device, rather than relying only on a model’s expressed intention. It can help detect file changes, process launches, and other concrete actions after authentication succeeds.

The different routes are complementary, but they compete to become the primary control plane. Identity vendors argue that every action should begin with a trusted actor and scoped authority. Network vendors see gateways as central inspection points. Endpoint vendors focus on observable execution.

RSAC 2026 showed how quickly these categories were converging. VentureBeat’s review of agent security frameworks found that major vendors had introduced registries, gateways, identity objects, and runtime monitoring.

The remaining gaps reveal why no single control is sufficient. An agent might pass every credential check and still modify the policy governing its own behavior. A gateway might see each tool call without reconstructing a delegation chain. An endpoint sensor might observe an action without knowing whether the agent had valid business authority.

Multi-agent delegation creates the hardest case. Suppose a procurement agent asks a research agent to compare suppliers. The research agent then creates a browsing agent, which requests documents from a third-party service.

Each handoff should narrow or preserve authority, never silently expand it. The final service needs enough evidence to determine who initiated the task, which agents participated, and whether the requested action fits the original purpose.

Traditional user impersonation performs poorly here. If every child agent inherits the employee’s identity, downstream systems cannot distinguish the original user from autonomous delegates. Revoking one compromised child may require terminating the entire user session.

A better model gives each agent a distinct identity while retaining a signed delegation chain. The child receives only the subset of permissions needed for its assignment. Logs preserve the relationship between the human owner, parent agent, child agent, and resulting action.

This structure resembles how secure cloud workloads exchange short-lived credentials. Yet agents introduce uncertain behavior and natural-language goals. Policies must account for both technical identity and changing task context.

There is also a practical integration problem. Enterprises already operate identity providers, privileged-access systems, API gateways, service meshes, endpoint agents, and security monitoring platforms. Adding a separate agent identity layer can create another console and source of truth.

The winning approaches will need to connect with existing identity infrastructure. Security teams will resist systems that require every application to adopt a proprietary protocol or maintain a duplicate employee directory.

That pressure favors standards-based claims, short-lived tokens, and portable audit records. It also favors products that can discover shadow agents before those agents request formal enrollment.

Discovery matters because employees can install coding assistants or connect local agents without security approval. A perfect identity policy does nothing for an agent that the organization does not know exists. Network, endpoint, cloud, and identity telemetry all contribute to finding those deployments.

The market’s convergence therefore supports Hush’s premise without validating every product claim. Identity is becoming necessary, but it will operate beside gateways, sandboxes, endpoint monitoring, and data controls. The real contest concerns which layer defines the authoritative record.

Identity Does Not Make an Agent Safe

A verified identity improves control and accountability, but it does not prove that an agent’s behavior is trustworthy.

This limitation is the strongest challenge to an identity-first narrative. An authenticated agent can still make a poor decision, follow a malicious instruction, expose data, or invoke an unsafe tool. Identity tells defenders who acted. It does not guarantee that the action was sensible.

Traditional security offers a warning. Legitimate accounts cause many damaging incidents because attackers steal credentials, employees receive excessive access, or approved software behaves unexpectedly. A valid identity is only the beginning of a policy decision.

Agent systems add uncertainty because their plans can change during execution. A model may select a different tool after reading new information. It may misunderstand a constraint or treat untrusted content as an instruction.

This is why sandboxing remains important. A sandbox isolates execution so a compromised or mistaken agent cannot freely affect the host system. Identity can limit permitted resources, while isolation constrains what the process can reach technically.

Prompt and output controls also retain a role. They can catch known attack patterns, sensitive data, or prohibited content before a request reaches another system. Their weakness lies in treating semantic interpretation as the only defense.

A complete architecture needs defense in depth. The identity layer establishes the actor and delegated authority. The gateway enforces connection policies. The sandbox limits execution. Endpoint and cloud monitoring record actual behavior. Data controls restrict sensitive information.

The policy engine must remain outside the agent’s control. If an agent can edit the rules that define its own permissions, a valid identity might help investigators attribute the damage without preventing it.

Credential protection presents another risk. Giving every agent a unique long-lived secret would improve attribution while multiplying the number of secrets attackers can steal. Identity systems should issue short-lived credentials and keep reusable secrets outside the agent’s environment.

Organizations must also avoid permanent agent sprawl. Automatically creating identities is useful, but inactive identities need automatic expiration. Otherwise, the enterprise replaces unmanaged API keys with unmanaged agent accounts.

Human ownership can become misleading as well. Mapping an agent to an employee does not mean that employee reviewed every action. Accountability records should distinguish sponsorship, approval, operation, and execution.

A manager may approve a workflow while a developer deploys the agent and another employee starts a task. Compressing all three roles into one “owner” field can create false certainty.

Data provenance needs similar care. An agent may combine documents, generated text, tool responses, and remembered context. Security logs should preserve which information influenced important actions, without collecting more sensitive content than necessary.

For knowledge workers, this issue extends beyond cybersecurity. Agents increasingly act on personal notes, project documents, transcripts, and prior decisions. A well-organized personal knowledge base can improve context, but access still needs clear boundaries.

An agent preparing a weekly update may need selected project records. It should not inherit unrestricted access to every private note merely because all information belongs to one user. Identity and task scope help separate useful context from unnecessary exposure.

Hush’s claims therefore require independent validation in production environments. Buyers should ask whether its system identifies agent instances cryptographically, integrates with existing identity providers, and propagates identity to downstream tools.

They should also test revocation speed, policy failure behavior, delegation tracking, and log completeness. A control plane that loses context during a tool call or defaults to broad access during an outage can recreate the risk it promises to reduce.

The company’s funding and product announcement establish market intent, not measured security outcomes. Public evidence does not yet show how the platform performs across every desktop, cloud, and managed-agent environment.

That uncertainty does not invalidate identity-first architecture. It defines the standard against which products should be evaluated. The useful question is not whether a dashboard lists an agent. It is whether identity consistently limits, attributes, and terminates that agent’s authority.

What Google News Readers Should Watch Next

Three signals will show whether agent identity becomes real infrastructure or remains a security marketing category.

The first signal is adoption of distinct identities in production. Security teams should look beyond the number of agents discovered or registered. The meaningful measure is how many active agents stopped using shared credentials or unrestricted human tokens.

Evidence of change would include short-lived credentials, task-scoped access, automatic expiration, and downstream services that retain the agent identifier. If shared keys remain common, gateway adoption alone will not resolve the accountability gap.

This signal will strengthen the identity-first argument when enterprises report fewer shared service accounts and more revocable agent sessions. It will weaken the argument if identity products remain limited to inventory dashboards while runtime access stays unchanged.

The second signal is support for delegation chains. Enterprise agents will increasingly create subtasks, call specialized agents, and cross organizational boundaries. Products must preserve authority across those handoffs.

A credible implementation should show the original human sponsor, every participating agent, the permissions transferred, and the resulting actions. Each child identity should receive no more authority than its parent can delegate.

Watch standards bodies and vendors for interoperable ways to express those relationships. Proprietary delegation records may work inside one platform, but enterprises use agents from several providers. Cross-platform verification will determine whether identity remains intact outside a vendor’s environment.

This signal strengthens the thesis if MCP tools, agent platforms, and identity providers can exchange verifiable delegation evidence. It weakens it if every platform translates agents back into ordinary user tokens at the boundary.

The third signal is incident containment. Identity matters most when an agent behaves incorrectly or is compromised. Vendors need to demonstrate that defenders can isolate one agent without disabling an employee, application, or entire workflow.

Useful tests include immediate revocation, denial of existing sessions, blocking of child agents, and reconstruction of the action chain. Organizations should also verify that policy enforcement fails safely when identity infrastructure becomes unavailable.

Security teams should compare logs from identity systems, gateways, endpoints, and downstream applications. If those records cannot be correlated, the enterprise still lacks one reliable account of the incident.

Success would strengthen Hush’s position by showing that agent identity changes outcomes, not just visibility. Repeated incidents involving authenticated but uncontained agents would show that the market overestimated identity as a standalone defense.

The Google News framing gets the order mostly right. Enterprises should establish who an agent is, whose authority it carries, and how long that authority lasts before treating a gateway as sufficient governance.

The next step is practical: audit one production agent from creation through its final tool call. Can your team identify its owner, task, credentials, permissions, subagents, data access, and revocation path? If any answer depends on a shared token or an inference from traffic, the gateway arrived before the identity foundation was ready.