In the span of three days this month, a large identity governance vendor, a machine identity vendor, and a newly funded startup each described how they plan to secure AI agents. The product names differ. The control lists are close to identical: find every agent, take away standing access, check actions at runtime, and be able to shut an agent down.
None of those ideas is new. They are identity controls that security teams already apply to people, service accounts, and privileged sessions. That is useful news for buyers, because it means the questions to ask are ones you already know.
What was announced
SailPoint (October 6). At its Navigate 2026 event, SailPoint announced updates to its Agentic Fabric, including shadow AI discovery, runtime authorization, an agent kill switch, and prompt monitoring. It also described just-in-time provisioning with conditions such as business justification or reauthentication, and a new Agent Audit feature that produces evidence reports from agent governance activity. SailPoint says these capabilities roll out starting at Navigate, with some items expected later in its fiscal year.
AppViewX (October 6). AppViewX expanded its Agent Identity Security product. The release describes discovery of sanctioned and unsanctioned agents, including browser-based and short-lived script agents; an MCP gateway with just-in-time access; and an agent kill switch that can act on signals from other tools through the Shared Signals Framework. It also describes issuing agent identities that chain to a customer's PKI. No general availability date was given.
Rein Security (October 8). Rein raised a $25 million Series A co-led by Glilot Capital and Sienna Venture Capital, according to SecurityWeek. The company describes its platform as providing visibility into agent behavior, real-time guardrails, governance, and supply chain security for AI agents.
Four controls, all familiar
Inventory. Every announcement starts with discovery, including agents nobody approved. This is the same problem as orphaned accounts and unmanaged service accounts. You cannot govern an identity you do not know exists.
No standing privilege. Just-in-time access for agents mirrors what privileged access management has done for administrators: grant access for a task, with a reason, and let it expire.
Runtime authorization. Checking each agent action against policy at the moment it happens is a policy decision point. The difference from a human session is speed and volume, which makes static, login-time checks less useful.
Revocation. A kill switch is session termination. AppViewX's reference to the Shared Signals Framework matters here, because revocation that works only inside one vendor's product leaves gaps when an agent spans several systems.
What the announcements leave open
The releases describe controls. They say less about three questions buyers will face.
Who owns the agent? Access reviews need an accountable human. If an agent is built by one team, runs under another team's credentials and acts for a third, someone has to answer for its permissions.
On whose behalf it acts. An agent acting for a specific user should not hold more access than that user. The chain of delegation needs to be recorded, not inferred after an incident.
When it ships. Several capabilities are described as rolling out or expected in coming quarters. Evaluate what is generally available today, not what is on a roadmap slide.
SailPoint cites its own research finding that 79% of enterprises run AI agents in production and 2% have deployed purpose-built identity security for them. The release does not give methodology, so treat those numbers as directional.
Questions to bring to any vendor
- 1.How do you discover agents that were never registered, and how often?
- 2.Whose permissions is the agent actually running on?
- 3.Can access be scoped to a single task and expire automatically when it ends?
- 4.Where is the policy decision made, and what context does it see?
- 5.How fast does revocation take effect across systems you do not control?
- 6.How do you record the human owner and the user an agent acted for?
Why NewCore
Accountability is an identity problem, and NewCore treats it as one. Its policy engine decides what each agent may do, and identity ties every decision to the agent, its authority, and an accountable owner. Here is how it answers the six questions above.
1. Can you see every agent you have?
NewCore connects read-only to your identity providers, your HR systems, and the AI platforms you've rolled out: Copilot Studio, AWS Bedrock, Claude Enterprise, and ChatGPT Enterprise. Nothing in those systems changes, and no agent has to be re-registered. You get one map of your people and your agents. Orphaned agents are flagged, along with people who left but are still active somewhere. Agents on platforms NewCore doesn't connect to aren't in that map.
2. Whose permissions is it really using?
The NewCore Gateway caps every agent at the permissions of the person it acts for. This means agents inherit the user’s permissions at most, never more. If a person can’t do it in the app, neither can their agent.
3. Is access scoped, and does it expire?
Agents get access, never credentials. NewCore brokers every tool credential. The agent holds only a short-lived token that works through the NewCore Gateway, for the tools policy allows. If that token leaks, it’s useless anywhere else.
4. Where the decision is made?
In NewCore's policy engine, it is enforced at the gateway before the call reaches the application. You bring one application under policy at a time and decide, action by action, what agents may do: allow, need approval, or blocked. In email, for example, an agent might search and read freely, need approval to send, and never create a forwarding rule. Same identity. The decision changes with the action. Policy can be set per agent, platform, user, or group. The most specific rule applies, and any action without a matching rule is blocked. Approving everything is approving nothing, so only the actions you flag wait for an authorized person. The alert shows the agent, the application, and the action, and the call fails closed if nobody answers.
5. Revocation?
Each approved AI client gets its own credentials from NewCore, so one client can be switched off without affecting the others, and any agent can be cut off on its next request. The limit: NewCore governs the calls that go through its gateway. Closing the direct paths in your IdP, in each AI platform's own connectors and through MDM on managed devices is part of deployment. AI built into other tools, coding agents calling CLI tools and MCP servers in private networks still go around it.
6. Is there a record of who acted for whom?
Every request, decision, and approval through the gateway lands in the Agent Log, tied to both the agent and the person behind it, along with policy changes and connections. The chain of delegation is recorded, not reconstructed after an incident.
Where we're headed: approvals that know why. NewCore will weigh what the agent was asked to do, what it has done before, and how risky the action is, so routine work proceeds and only the exceptions reach a person.
Adoption starts with read-only discovery and then goes one application at a time, so risk drops with each app brought under policy.
Agents act. People stay accountable. The enterprise can prove it.
Takeaway
Agent security is being sold as a new category. The working parts are inventory, least privilege, runtime policy and revocation, applied to a faster-moving kind of identity. Teams with mature identity programs are closer to ready than the marketing suggests, and teams without them will find the agent problem harder, not easier.