Israel’s Cyber Industry Bets on Identity as the Next AI Security Battleground

Israel’s cyber industry has made a specific bet now surfacing across Google News: identity controls will become the first defense against autonomous AI agents.

That bet changes how security vendors define the AI threat. The immediate problem is no longer limited to malicious prompts, unsafe model outputs, or confidential data entering a chatbot. It is increasingly about software agents receiving credentials, calling tools, and changing business systems without continuous human approval.

Israeli companies including CyberArk, Oasis Security, Apono, Silverfort, and Astrix Security approach that problem from different positions. Yet their direction is remarkably consistent. Each treats an AI agent as an active identity whose access must be discovered, limited, monitored, and revoked.

The emerging contest is therefore larger than one product category. Traditional identity systems grant permissions to predictable users and applications. The newer model must govern software that interprets instructions, selects tools, delegates work, and changes its behavior as context changes.

That creates the central tension. Enterprises want agents to complete useful work without waiting for approval at every step. Security teams need enough control to stop one compromised agent from turning legitimate access into authenticated abuse.

The Israeli Bet Is Moving From Funding Thesis to Product Strategy

Identity security has become a practical product race because AI agents are beginning to cross the boundary between generating answers and taking actions.

The evidence is visible across several Israeli vendors. CyberArk introduced Secure AI Agents as an extension of its identity security platform. The product applies privilege controls to autonomous agents across cloud, software, and developer environments.

Oasis Security has moved from non-human identity discovery toward what it calls agentic access management. Its approach evaluates what an agent is trying to accomplish before granting narrowly scoped permissions for that task.

Apono launched Agent Privilege Guard around the same principle. The service connects agent activity to just-in-time access, meaning credentials become available only when a specific action requires them. Those permissions can then expire instead of remaining attached to an account.

Silverfort and Astrix Security entered from adjacent parts of the identity market. Silverfort has focused on extending authentication and identity protection across enterprise systems. Astrix has concentrated on non-human connections, service accounts, tokens, and application access.

These companies are not offering identical technology. Some begin with discovery, others with privileged access, authorization, or threat detection. Their shared premise matters more than their differences: an AI agent must not inherit broad authority merely because a human initiated its task.

That premise gained commercial weight when Oasis reported substantial enterprise demand and a major funding round. According to a company funding profile, Oasis said its new annual recurring revenue grew fivefold over the preceding year.

The company also said most customers were large enterprises, with many signing multi-year contracts. Those claims have not been independently audited in the public reporting. They still indicate that identity controls are moving closer to core infrastructure budgets.

CyberArk supplied another signal when it made its agent security product generally available. Its agent security release described discovery, secure access, real-time detection, and lifecycle management as one connected control layer.

That packaging is important. It turns AI agent security from a specialized model-safety problem into an extension of identity operations. The buyer becomes the team already responsible for credentials, permissions, privileged accounts, and access reviews.

This shift also explains why established platforms and younger startups can compete in the same market. Large vendors possess enterprise distribution and existing identity data. Startups can redesign authorization around short-lived, dynamic agent activity without supporting decades of legacy architecture.

The race has moved beyond predicting a future threat. Vendors now need to prove that their controls work inside real agent workflows without making those workflows unusably slow.

Why Google News Is Filling With AI Identity Security

The increase in Google News coverage reflects a real architectural change: AI systems are acquiring the ability to act through trusted enterprise connections.

A conventional chatbot produces text for a person to review. An AI agent can call an application programming interface, query a database, update a customer record, or initiate a software deployment. Each action depends on some form of identity and delegated authority.

That authority creates a larger risk than an incorrect answer alone. A hallucinating chatbot can mislead its reader. A hallucinating agent with write access can alter production data before anyone notices the error.

The distinction also changes the meaning of authentication. Authentication establishes which identity is making a request. Authorization determines whether that identity can perform the requested action. An agent needs both, but neither control is sufficient when applied only once.

Consider a coding agent asked to diagnose a production incident. It might need read access to logs, temporary access to a repository, and permission to restart one service. Giving it permanent administrator credentials would make the task easier, but it would also enlarge the damage from prompt injection or compromise.

A safer design gives the agent a unique identity and grants limited permission for the immediate task. The system records who requested the action, which agent executed it, what resources it touched, and when its access expired.

This approach is often described as least privilege, just-in-time access, or zero standing privilege. Least privilege limits access to what a task requires. Just-in-time access grants it only when needed. Zero standing privilege removes persistent authority between approved operations.

These are established security concepts. The difficult part is applying them to agents that reason across several steps and can call other agents. The authorization system must distinguish legitimate adaptation from behavior that has moved outside the approved task.

The issue has become significant enough to attract standards work. In February 2026, the US National Institute of Standards and Technology announced an initiative focused on interoperable and secure AI agents.

Its agent standards initiative includes research into agent authentication, identity infrastructure, and secure interactions between humans and agents. NIST also proposed work covering authorization, auditing, non-repudiation, and prompt-injection controls.

Non-repudiation means creating evidence that an identified party performed a particular action. It becomes difficult when one human request triggers several agents, temporary credentials, and automated tool calls.

Google News is therefore capturing more than a coordinated marketing campaign. Standards bodies, established vendors, investors, and enterprise security teams are converging on the same unresolved control point.

However, repeated coverage does not establish which vendor architecture will win. It shows that the problem has become legible enough for several markets to form around it.

Those markets include agent discovery, credential management, runtime authorization, identity threat detection, audit trails, and policy enforcement. They will overlap, and buyers will resist operating a separate console for every layer.

The eventual winners must connect these functions without confusing visibility with control. Finding an agent is useful. Showing its excessive permissions is better. Preventing an unsafe action while allowing legitimate work is the harder and more valuable step.

Autonomous Agents Are Pressuring Traditional Access Control

The primary contest is between static permissions designed for predictable software and runtime authorization designed for agents whose actions change with context.

Traditional identity and access management works well when administrators can define a stable relationship between a user, a role, and a resource. An accountant belongs to a finance group. A server receives a service account. A scheduled application uses a known credential.

AI agents weaken those assumptions. One agent might summarize documents during one session, update a project tracker during another, and invoke deployment tooling during a third. Its required authority changes with the goal, environment, and data.

Role-based access control can assign the agent a predefined role. Yet a broad role risks granting more access than one task requires. Creating a new role for every temporary task can produce administrative overload.

Intent-based access attempts to solve that problem by evaluating the proposed action and its purpose at runtime. Oasis and Apono both use versions of this language, although their implementations and enforcement points differ.

Apono says its privilege guard can place access decisions between an agent and enterprise infrastructure. Higher-risk requests can trigger human approval, while permitted tasks receive temporary access.

Oasis describes a process that converts an agent’s intended work into a more precise action plan. Its system can then calculate which resources and permissions that plan requires.

The promise is attractive. An agent can keep moving through low-risk operations while security policy blocks or escalates sensitive actions. Enterprises gain automation without handing the model permanent administrative authority.

The challenge lies in determining intent reliably. A natural-language request does not always predict the final sequence of tool calls. Context can change, external data can contain hostile instructions, and an agent can delegate part of its task.

A policy engine must therefore evaluate more than the original prompt. It needs the agent’s identity, human sponsor, requested resource, current action, credential scope, environmental risk, and previous behavior.

That requirement pressures incumbent identity vendors. Their existing systems contain valuable information about users, groups, accounts, and permissions. They may lack detailed context about why an agent is invoking one tool at a particular moment.

Startups face the inverse problem. They can build around dynamic agent behavior, but they must integrate with many clouds, databases, software platforms, and identity providers. An authorization product cannot protect a connection it does not see.

The resulting competition is not simply startup versus incumbent. It is a contest over the control plane, meaning the layer where organizations define and enforce who can do what.

CyberArk brings privileged access management and existing enterprise relationships. Okta brings workforce identity and application access. Cloud platforms control many of the credentials agents will use. Agent developers can also place authorization inside their own frameworks.

This fragmentation creates an uncomfortable question for buyers. Should agent authority live in an identity platform, a cloud security product, the agent framework, or a dedicated enforcement gateway?

Placing control only inside the agent is risky because a compromised agent cannot serve as its own trusted guard. Placing every decision in an external gateway can introduce latency and miss context held inside the agent.

The likely architecture will divide responsibility. Agent frameworks will provide task context and traceability. Independent policy systems will issue scoped credentials and enforce limits. Identity platforms will maintain ownership, lifecycle, and audit records.

That division still needs common standards. Without them, every vendor will describe agents, delegated authority, and action logs differently. Enterprises could end up with several incompatible identity records for the same autonomous process.

For engineering teams, this is also a knowledge problem. Security policies depend on understanding which agent accessed which local documents, repositories, and internal tools. A searchable engineering knowledge base can improve context, but authorization must remain separate from retrieval.

The important boundary is straightforward. Access to useful context does not imply permission to change the source system. Retrieval, reasoning, and execution require distinct controls.

The Identity Thesis Solves Access, Not Every AI Risk

Treating agents as identities creates a necessary control point, but it does not make their reasoning predictable or their instructions trustworthy.

The strongest criticism of the identity thesis is not that access control is irrelevant. It is that identity vendors may frame a broader AI safety problem around the products they already know how to sell.

An authenticated agent can still perform a harmful action. The system may know exactly which agent deleted a record and still fail to prevent the deletion. Identity establishes accountability, not correctness.

Least privilege also depends on accurate policy. If an agent legitimately needs broad access for a complex task, the permitted blast radius remains large. A narrowly scoped credential can still authorize the wrong operation within that scope.

Prompt injection creates another gap. A malicious instruction hidden inside a document or web page can redirect an agent’s behavior. The agent remains properly authenticated while acting on an untrusted input.

Runtime authorization can limit the consequences, but only if policy recognizes that the requested action exceeds the intended task. That recognition becomes harder when the malicious request resembles normal work.

Delegation complicates attribution further. A user can authorize one agent, which then calls another agent through an external service. The second agent might invoke several tools under credentials derived from the first request.

Security teams need an evidence chain connecting the human sponsor, primary agent, delegated agents, issued credentials, tool calls, and resulting changes. Missing one link can make a complete audit impossible.

Researchers have also questioned whether treating agents like human identities creates the wrong abstraction. A human identity is relatively persistent and has legal accountability. An agent can be duplicated, modified, terminated, or recreated during one workflow.

Some architects prefer to treat agents as temporary workload principals. A principal is an entity recognized by an authorization system. This framing emphasizes the specific runtime process instead of giving an agent a durable employee-like identity.

The difference may sound semantic, but it affects policy design. A persistent identity helps track history and ownership. A temporary principal limits credential reuse and better reflects short-lived execution.

A mature architecture may require both. The organization needs a durable record describing the agent and its owner. Each execution should also receive a distinct runtime identity with limited authority.

Another uncertainty concerns vendor claims. Security companies can demonstrate that they discover known agents and broker supported connections. Proving that they cover every shadow agent, copied credential, or indirect tool call is much harder.

Coverage also changes as employees adopt new agent tools. A developer might connect an assistant to a repository using a personal token. A department might deploy an agent through a software service without informing the security team.

Discovery systems can scan cloud environments and software integrations, but no tool guarantees complete visibility. Buyers should treat inventory percentages and automated ownership claims as vendor-reported unless independently tested.

Survey data requires similar caution. CyberArk reported that nearly 40 percent of surveyed financial and software organizations already had agentic AI in production. Fewer than one in ten reportedly had scaled agent security controls.

That research covered 104 security leaders in North America and Europe. It describes a concerning gap within that sample, not the entire global enterprise market.

Broader reporting presents the same direction with different estimates. An agent identity analysis noted that security vendors were racing to govern autonomous systems as enterprises expanded agent pilots.

The report also captured a critical operational idea: organizations need a way to revoke an agent immediately. A kill switch does not resolve every failure, but it provides a final control when automated policy and monitoring break down.

Buyers should test that capability under stress. Revocation must propagate across active sessions, cached tokens, delegated agents, and downstream tools. Disabling one visible account is insufficient if its temporary copies remain active.

Identity security therefore addresses the part of AI risk that enterprises can govern most directly. It controls authority, records actions, and limits exposure. It does not guarantee safe reasoning, accurate decisions, or trustworthy inputs.

That limitation does not weaken the category. It clarifies what the category must prove.

The Market Is Consolidating Around the Control Plane

The identity opportunity is attracting both focused startups and large security platforms because agent access sits between valuable data and automated action.

Palo Alto Networks’ acquisition of CyberArk made the strategic stakes especially clear. The combination places identity security beside network, cloud, endpoint, and security operations products.

The transaction suggests that identity is becoming a horizontal layer across security portfolios. If AI agents touch applications, infrastructure, and sensitive data, their permissions connect several markets that vendors previously sold separately.

Google’s acquisition of Wiz provided another reference point for Israeli cybersecurity. Wiz built its position around cloud visibility and risk relationships. Agent identity extends that graph toward the question of which autonomous process can act on each resource.

Large platforms can combine access data with network signals, cloud configuration, and threat intelligence. That breadth helps them detect when a legitimate identity behaves abnormally.

It can also create integration risk. A platform assembled through acquisitions may expose several policy engines, identity records, and administrative interfaces. Customers will judge whether the components function as one control system or remain loosely connected products.

Focused startups argue that older platforms were built for human users, conventional applications, or static service accounts. Their advantage is the ability to model ephemeral agents and task-level permissions from the beginning.

Incumbents counter with distribution and installed infrastructure. Enterprise buyers already trust them to manage privileged accounts or authenticate employees. Adding agents to an existing identity platform can be easier than introducing another security vendor.

Cloud providers hold a third position. They issue many workload credentials and control the infrastructure where agents run. They can embed short-lived identities, policy evaluation, and logging close to the execution environment.

Application vendors hold another piece. An agent accessing customer data through a software service depends on that service’s authorization model. External identity controls cannot create fine-grained permissions that the underlying application does not support.

The market could therefore split across several layers:

• Identity platforms maintain agent ownership, lifecycle, and organization-wide policy.

• Cloud systems issue workload identities and temporary credentials.

• Agent frameworks expose task context, delegation, and tool activity.

• Enforcement gateways evaluate high-risk operations before execution.

• Security analytics products detect abnormal behavior after access is granted.

• Applications enforce the final resource-level permission.

This structure creates partnership opportunities, but it also invites consolidation. Buyers will prefer fewer policy surfaces, especially when every additional integration can become another point of failure.

The Israeli industry’s advantage is its dense network of identity, cloud, and enterprise security expertise. Founders and employees frequently move between military technology units, startups, multinational research centers, and public security companies.

That network does not guarantee market leadership. American platform vendors, cloud providers, and identity specialists such as Okta and 1Password are pursuing the same opportunity.

Open-source frameworks can also influence where enforcement occurs. If agent developers adopt common identity and authorization interfaces, vendors can compete on implementation. If each framework creates its own model, larger platforms may gain leverage through integration coverage.

Standards will shape that balance. NIST’s work asks how organizations can identify agents, authorize them, audit their actions, and connect activity to responsible humans.

A common model would reduce integration costs and make vendor claims easier to compare. It could also limit attempts to turn proprietary agent identity formats into customer lock-in.

The control plane will not belong automatically to the company with the largest existing identity business. It will belong to the architecture that combines trustworthy context, independent enforcement, broad integration, and usable operations.

What Buyers Should Watch After the Google News Cycle

The next stage will be decided by technical validation and enterprise behavior, not by the volume of Google News headlines.

The first signal is whether runtime authorization survives complex delegation. Product demonstrations often show one agent requesting access to one resource. Real deployments will involve agents that call tools, spawn subprocesses, and delegate work across organizational boundaries.

Buyers should ask whether every delegated action receives its own traceable identity and credential. They should also test whether revoking the original request disables all descendant access.

If vendors can enforce that chain consistently, the identity thesis becomes stronger. If control disappears after the first delegation, the market is still solving simple automation rather than autonomous agent security.

The second signal is convergence around standards. NIST has already defined agent identity and authorization as a formal area of work. The important outcome will be interoperable implementation, not another collection of principles.

Enterprises should watch for common formats covering agent ownership, delegated authority, action provenance, and credential scope. Adoption by cloud platforms and agent frameworks would matter more than support from security vendors alone.

A shared standard would strengthen the market by making policies portable. Continued fragmentation would favor large platforms that can absorb integration costs and maintain proprietary identity graphs.

The third signal is evidence of routine enterprise use. Funding rounds and vendor surveys establish interest, but they do not prove that organizations can operate these controls at scale.

Useful indicators include how many agent actions receive temporary credentials, how often policy blocks unsafe requests, and how quickly teams can investigate delegated activity. Buyers should also measure false positives and approval delays.

An authorization system that blocks too little creates risk. One that interrupts ordinary work will be bypassed. The winning products must demonstrate that they can narrow access without turning every tool call into a manual ticket.

Security leaders can begin before choosing a platform. They should inventory agents, service accounts, API tokens, and agent-connected applications. Each agent needs an accountable owner and a documented path for immediate revocation.

Teams should separate read access from write access and distinguish routine actions from irreversible ones. High-risk operations need stronger approval, shorter credential lifetimes, and clearer audit evidence.

Developers should avoid placing permanent secrets inside prompts, configuration files, or agent memory. Short-lived credentials reduce exposure, but they must remain bound to the approved task and runtime identity.

Knowledge workers also have a role. Connecting an assistant to email, documents, calendars, and project systems can give it more authority than its visible interface suggests. Users should understand which actions require review and which occur automatically.

The story emerging through Google News is therefore credible but incomplete. Israeli cybersecurity companies have identified identity as the enforceable boundary between agent reasoning and enterprise action.

They have not yet proved that one architecture can govern every agent, tool, credential, and delegated task. Standards remain unfinished, enterprise measurements remain limited, and vendor coverage claims require testing.

The practical question is no longer whether agents need access controls. It is whether those controls can follow authority through an entire autonomous workflow.

Organizations should watch the next product integrations, standards implementations, and deployment evidence closely. If those three signals align, identity will become the operating layer for enterprise AI security. If they do not, the current attention will expose a problem before the market has produced a complete answer.