NewCore raises $66M to solve the identity mess AI agents are about to create

NewCore came out of stealth this week with $66 million in seed funding and a narrow, believable bet: companies are going to give AI agents access to internal systems, and the current identity stack won’t handle that cleanly at scale.

Cyberstarts led the round, with Index Ventures and Evolution Equity Partners participating. TechCrunch reports the company is valued at $300 million post-money. That’s a big seed round, but the premise is easy to understand if you’ve ever cleaned up service accounts, long-lived API keys, stale permissions, or forgotten automation credentials.

AI agents make all of that worse.

NewCore wants to manage human employees, machines, and AI agents in one identity system. Its pitch is that agents need first-class identities: their own permissions, lifecycle policies, audit trails, and revocation paths, instead of being shoved into service accounts or shared credentials.

That distinction matters. Many enterprise AI deployments still treat agents like scripts with nicer interfaces. They get a token, a credential, a browser session, or delegated access from a human user. That can survive a demo. It’s a weak operating model once agents start filing tickets, reading repositories, querying data warehouses, opening pull requests, or touching production-adjacent systems.

Why agent identity is becoming a security problem

The enterprise identity stack was mostly built around people.

A user joins the company. They’re provisioned through Okta, Microsoft Entra, Ping, or another identity provider. They get groups, apps, roles, and device policies. When they leave, their access is removed, at least in theory.

Machines came later through service accounts, workload identities, API keys, certificates, secrets managers, OAuth clients, and cloud IAM roles. That system is already messy, but teams have learned to work around it.

AI agents blur the line.

An agent might behave like an employee when it reads Slack, writes code, and responds to a Jira issue. It might behave like a workload when it calls APIs. It might act as a delegated assistant for a human user. It might run for five minutes, or persist for months as a semi-autonomous worker assigned to a team.

That raises practical questions security teams can’t ignore:

• Who owns the agent?
• What systems can it access?
• Can it request new permissions?
• Does it inherit a user’s privileges or get its own?
• How do you revoke access without breaking a workflow?
• What happens when the agent changes model provider, prompt, toolchain, or behavior?
• How do you audit intent, action, and authority separately?

Current identity systems can answer some of this, usually through patchwork. That’s the gap NewCore is going after.

Co-founder and CEO Zohar Alon argues that identity platforms built 15 or 20 years ago will struggle with the volume and complexity of AI agents. He has credibility in this market. Alon previously founded Dome9, a cloud security startup acquired by Check Point. NewCore’s other co-founders are CTO Amihai Neiderman, formerly a Unit 8200 research leader and founder of Nym Health, and chief commercial officer Erez Yarkoni, previously CIO at T-Mobile USA and Telstra.

The founding team is clearly built for enterprise security buyers, not hobbyist AI tooling.

The scale claim is plausible, but the timing is murky

NewCore’s core assumption is that AI agents will eventually outnumber human employees in many technical organizations. That sounds aggressive until you look at how automation spreads inside companies.

A single engineering org could end up with coding agents for repo maintenance, dependency updates, test generation, incident triage, log analysis, cloud cost review, and customer support escalation. Data teams may run agents for pipeline monitoring, schema drift detection, notebook cleanup, feature store checks, and BI query assistance.

Most won’t resemble full employees. They’ll be specialized workers with narrow scopes. From an identity and access perspective, each still needs a name, an owner, a policy, and a kill switch.

Goldman Sachs has tested Cognition’s Devin as a coding agent “employee.” McKinsey has said 25,000 AI agents already work alongside its 60,000 employees. TCS chairman N. Chandrasekaran has also said AI agents could eventually rival the company’s workforce in size.

Those claims need caution. Companies use “agent” loosely, and many so-called agents are structured workflows with LLM calls added in. The access-control problem doesn’t require full autonomy, though. Even limited agents can cause damage if they hold broad credentials and operate across internal systems.

Security teams have already seen the pattern with cloud permissions. Over-permissioned identities start as a shortcut and become a breach path.

Service accounts won’t be enough

A service account is usually tied to an application, script, or backend process. It often has stable permissions and predictable behavior. That model starts to break when the “process” is an AI agent that can interpret instructions, select tools, call APIs, generate code, and act on changing context.

Using a shared service account for an agent creates obvious problems:

• Weak attribution, since multiple agents or users may act through the same identity
• Permission sprawl, because broad access is easier than careful policy design
• Poor lifecycle control, especially for temporary or experimental agents
• Messy audits, since logs show credentials being used but not always why
• Higher blast radius if a token leaks or the agent is manipulated

Delegating a human user’s access is risky too. If an agent acts through a developer’s session, it may inherit permissions never meant for automation. That can include production logs, source repositories, deployment systems, customer data, and internal admin panels.

The cleaner pattern is to give agents distinct identities and constrain them through policy. Identity systems then need to understand agent ownership, task boundaries, approval flows, tool access, expiry windows, and revocation. Those controls also need to plug into existing IAM, SaaS apps, cloud platforms, and developer tools.

That’s hard integration work. It’s also an area where a focused startup can move faster than a large identity vendor, at least early on.

What NewCore says it has built

NewCore says its platform manages human and AI identities together. It treats agents as managed identities with their own access rights and lifecycle controls.

One notable technical detail is the company’s “split-key” architecture. NewCore says it divides critical identity credentials between the customer and the platform to avoid a single point of compromise. The idea is sensible: don’t put all signing or credential authority inside one SaaS provider if that provider becomes a high-value target.

The trade-off is operational complexity. Split-key systems can reduce concentration risk, but they need careful recovery flows, latency handling, high availability design, and clean failure modes. If the identity plane becomes fragile, teams will route around it. Security products fail in practice when the safe path is too painful.

NewCore is also shipping an “Agentic Skill” integration package for coding assistants such as Anthropic’s Claude Code, OpenAI’s Codex, and Cursor. The goal is to let those tools access enterprise systems through managed identities instead of manually handed-out credentials.

That’s where this category will be tested first. Coding agents already sit close to sensitive assets: source code, secrets, CI/CD systems, dependency manifests, tickets, and internal docs. If an agent can open a pull request, inspect logs, and modify infrastructure-as-code, “use my token for now” is a bad control model.

NewCore also offers a mobile app for employees to grant, review, and revoke agent access. A human approval layer can help, but it carries its own risk: approval fatigue. If teams generate too many permission prompts, people will tap approve just to keep work moving. The product will need strong defaults, contextual prompts, and policy automation. Humans should review meaningful decisions, not babysit every API call.

The incumbents are already circling

Okta and Microsoft Entra are already adding agent-related identity features. That’s expected. They own major enterprise identity relationships, and CIOs don’t want another identity platform unless the pain is obvious.

NewCore’s argument is that incumbent platforms were designed around human users first, with agent support added later. That may be true architecturally, but it doesn’t guarantee NewCore wins. Identity is sticky. Procurement is slow. Integrations decide the market.

For NewCore to matter, it will need to fit into existing stacks rather than demand a rip-and-replace. Senior engineers and security leaders will care less about whether the product is “built for agents” and more about whether it answers practical questions:

• Does it integrate with Entra ID, Okta, Google Workspace, AWS IAM, Azure IAM, and GCP IAM?
• Can policies map to existing groups, roles, and approval workflows?
• Does it produce audit logs that SIEM and detection teams can use?
• Can it enforce least privilege without blocking developer workflows?
• How does it handle short-lived agents, ephemeral sessions, and delegated tasks?
• What happens when an agent calls another agent or toolchain?
• Can it support standards like OAuth 2.0, OIDC, SCIM, SAML, SPIFFE/SPIRE, or workload identity federation where appropriate?

This market won’t be won by a slick admin console alone. It’ll be won through boring compatibility and clean policy semantics.

A large seed round for a very early company

NewCore has more than 50 employees across the U.S. and Israel. It has fewer than 10 customers and more than 10 design partners, and it expects to start charging customers this summer.

That’s early. Very early.

A $300 million post-money valuation at this stage reflects investor belief that identity for AI agents becomes a major enterprise security category. It doesn’t prove product-market fit. NewCore still has to show that agent identity is urgent enough for customers to buy now, not after the first major agent-driven breach.

There’s also a naming problem across the industry. Vendors are calling everything an agent: chatbots, workflow automations, coding assistants, RPA bots with LLM wrappers, and genuinely autonomous systems. NewCore’s platform will need to handle that messy range without forcing customers into a rigid taxonomy.

The stronger version of the opportunity is straightforward. Enterprises will deploy many software actors that can reason, call tools, and act with partial autonomy. Those actors need identity controls that are more granular than machine credentials and less human-centric than employee directories.

That’s a real gap.

The weaker version is also possible. Enterprises may move slowly, restrict agents to narrow sandboxes, and rely on existing IAM plus secrets managers for longer than startups expect. Large identity vendors may ship “good enough” agent controls before NewCore gets deep distribution. Security teams already have too many dashboards.

What technical leaders should watch

For developers and AI engineers, the practical takeaway is simple: don’t treat agent access as an implementation detail.

If your team is building internal agents, define identity rules early. Give agents unique identities. Avoid shared credentials and borrowed user sessions. Set owners, scopes, expiry rules, approval paths, and revocation procedures before the agent touches sensitive systems.

The hard part won’t be naming the agent. It’ll be proving what it did, why it had permission to do it, and how quickly you can stop it when something goes wrong.