AI agents are stepping out of the lab and into the enterprise—quietly at first, then all at once. A customer support agent that drafts replies. A procurement agent that gathers quotes. A finance agent that reconciles anomalies. A developer agent that proposes patches. Each one starts as “just a tool,” but the moment it’s allowed to take actions—submit tickets, change records, call internal APIs, trigger workflows—it stops behaving like software you operate and starts behaving like an actor you govern.
That shift is exactly where NewCore is positioning itself. The company has emerged with $66 million in funding, and its core argument is blunt: the next wave of enterprise security won’t be about managing people. It will be about managing AI agents. Not in the vague sense of “monitoring AI usage,” but in the concrete sense of identity, permissions, accountability, and auditability for autonomous or semi-autonomous systems that can act on behalf of an organization.
The headline version of this story is funding. The deeper story is what the funding signals: enterprises are beginning to treat agents as operational participants, and that forces a new security conversation—one that looks less like traditional endpoint protection and more like identity and governance, except the “users” are not human and the “sessions” don’t always map cleanly to a single operator.
To understand why NewCore’s timing matters, it helps to look at how agent deployments typically evolve. Early pilots often keep agents constrained: they generate text, recommend actions, or produce drafts that humans approve. But as teams gain confidence, they loosen constraints. They add tools. They connect agents to internal systems. They allow multi-step workflows. They reduce friction. And eventually, the agent isn’t merely producing outputs; it’s executing tasks.
At that point, the enterprise runs into a familiar problem—except the subject is new. Traditional access control models assume a human identity (or a service account) that initiates requests. They also assume that the person behind the request can be traced, explained, and held accountable. With AI agents, those assumptions start to break down. An agent may use multiple tools, call several services, and make decisions based on context that changes from run to run. Even if every action is logged, the question becomes: which identity should be associated with the agent’s actions, and how do you prove that the agent was authorized to do what it did?
NewCore’s pitch is essentially that enterprises need agent identities—something more structured than “this model ran in this environment.” In other words, the identity layer shouldn’t just describe infrastructure. It should describe the agent as an entity with a defined role, permissions, and behavioral boundaries. If agents are going to behave like employees inside your systems, then they need the equivalent of onboarding, access policies, and audit trails.
What “agent identity” really means in practice
When people hear “identity,” they often think of authentication: proving who you are. But in enterprise security, identity is broader than login. It’s the binding between an actor and a set of rights, plus the ability to trace actions back to that actor. For humans, that’s straightforward: a user signs in, and their actions are attributed to their account. For services, it’s also manageable: a service account has credentials and permissions, and logs can be tied to that account.
Agents complicate the picture because they’re not always a single process with a single credential. Many agent architectures involve orchestration layers, tool-calling components, retrieval systems, and memory stores. An agent might “think” in one place, retrieve information in another, and execute actions through yet another service. If you only authenticate the final API call, you lose the thread of what the agent was authorized to do at the level of intent and workflow.
Agent identity, as NewCore frames it, is about making that thread explicit. Instead of treating agent execution as an opaque run, you define an agent identity that represents the agent’s role in your organization. That identity can then be linked to:
1) Permissions: What the agent is allowed to do across systems.
2) Boundaries: Which tools it can call, which data it can access, and under what conditions.
3) Accountability: How actions are attributed and audited.
4) Governance: How policies are enforced and updated over time.
This is not just a theoretical improvement. It directly affects incident response. If something goes wrong—data leakage, unauthorized changes, or a workflow that spiraled out of control—security teams need to answer questions quickly: Was the agent authorized? Did it follow policy? Which agent identity was responsible? If the agent was misconfigured, what changed? If the agent was compromised, how did the compromise occur?
Without agent identity, investigations become guesswork. With it, you can treat agent behavior as something you can attribute and govern, rather than something you can only observe after the fact.
Why the enterprise security problem is shifting
NewCore’s central claim—that the next challenge is managing agents, not people—lands because it reflects a real operational trend. Enterprises already have mature processes for human access: role-based access control, least privilege, periodic reviews, joiner/mover/leaver workflows, and compliance reporting. Those systems were built for a world where the actor is stable and the identity is persistent.
Agents are different. They can be created dynamically. They can be configured per project. They can be deployed temporarily for a specific workflow. They can also be updated frequently as prompts, toolsets, and retrieval sources evolve. That means the identity layer must be flexible enough to handle change while still being strict enough to enforce policy.
There’s also a second shift: the locus of risk. With traditional systems, risk often concentrates at the perimeter or at endpoints. With agents, risk concentrates at the decision-and-action boundary. The agent decides what to do next, and then it acts. If the decision is wrong—or if the agent is manipulated by malicious inputs—the action can be harmful even if the underlying infrastructure is secure.
This is why identity and governance matter so much. If you can’t reliably tie actions to an authorized agent identity, you can’t enforce least privilege at the right level. You can’t reliably prevent overreach. And you can’t reliably prove compliance.
NewCore’s funding as a signal of urgency
A $66 million round doesn’t automatically mean a product is ready for mass adoption, but it does indicate that investors see a market forming quickly. Agent deployments are accelerating, and security teams are feeling the pressure to catch up. The funding suggests NewCore is betting that enterprises will soon demand agent governance infrastructure rather than ad hoc solutions.
It also hints at a broader industry pattern: when a new class of “actors” emerges, the security stack tends to adapt around identity. We’ve seen this with cloud services, containers, and microservices. Each time, the actor model changed, and identity became the organizing principle for authorization, auditing, and policy enforcement.
Agents are the next actor model.
A unique angle: governance as an operational layer, not a policy document
Many security products begin and end with policy. They provide rules, checklists, and dashboards. Those are useful, but they don’t solve the hardest part of agent governance: ensuring that the agent’s runtime behavior stays within the intended boundaries.
NewCore’s framing implies a more operational approach. Instead of treating governance as something you write once and hope the system follows, the identity layer becomes part of the runtime contract. The agent identity is the mechanism that connects what the agent is allowed to do with what it actually does.
That’s a subtle but important distinction. In a typical enterprise environment, you can have policies that say “only approved systems can access sensitive data.” But if an agent can call tools indirectly, chain actions, or operate through orchestration layers, you need enforcement that travels with the agent’s actions—not just with the initial request.
In practice, this means governance needs to be able to answer questions like:
– Which agent identity initiated this tool call?
– Does the agent identity have permission for this specific action?
– Is the action consistent with the agent’s defined role and workflow?
– Can we reconstruct the sequence of actions for audit purposes?
– If permissions change, how quickly does the agent’s effective authority update?
These are runtime questions. They require runtime attribution and enforcement.
The “employee” analogy is more than marketing
Calling agents “employees” can sound like hype, but it maps to a real governance model. Employees have job descriptions, access levels, and accountability. They also have constraints: they can’t access everything, they can’t perform actions outside their role, and their actions are logged.
If agents are going to operate inside enterprise systems, they need the equivalent of:
– Role definition: what the agent is supposed to do.
– Access provisioning: what systems and data it can touch.
– Audit logging: what it did and when.
– Change management: how updates affect permissions and behavior.
– Incident handling: how to identify the responsible actor when something goes wrong.
NewCore’s emphasis on identity suggests it wants to bring agent governance closer to the maturity level enterprises already expect for human access.
And there’s another reason the employee analogy resonates: enterprises already know how to manage employees at scale. They have processes, tooling, and compliance frameworks. They don’t have equivalent frameworks for agent actors. That gap is what NewCore is trying to fill.
What enterprises should be thinking about now
Even if NewCore’s product details evolve, the underlying problem is already here. Enterprises deploying agents should start asking security questions that go beyond “is the model safe?” and instead focus on “can we govern the actor?”
Here are the kinds of questions that matter in the near term:
1) Attribution: Can every action taken by an agent be traced back to a specific agent identity?
2) Authorization: Are permissions enforced at the level of the agent’s role, not just at the level of the infrastructure?
3) Least privilege: Can the agent be restricted to only the tools and data it needs for its job?
4) Auditability: Can