The immediate lesson from SailPoint’s Navigate keynote is not about computer vision or natural language processing. It is that enterprise access control must move closer to the moment an AI agent acts. When software can retrieve data, call tools or change records on a person’s behalf, the central question becomes: who authorised that action, and can the permission be withdrawn selectively?
That matters to founders building AI products and to operators deploying them. Traditional identity governance often reviews access on a calendar. Agentic systems operate through continuous tool calls. The gap between those two speeds is becoming a product, security and accountability problem.
Why computer vision and natural language processing are not the governance layer
The model’s input format is not the main security decision. A system may interpret an image through computer vision, process text through natural language processing or work with structured records. In each case, the important questions are the same: which identity initiated the task, what is the agent allowed to do, which data can it access and what happens when its behaviour changes?
This distinction is easy to miss. Teams often evaluate a model’s accuracy, prompt behaviour or reasoning quality before defining the authority surrounding it. That reverses the order of operations. A capable model with poorly scoped permissions can create a business-control problem even when its output is technically sound.
The shift from periodic review to runtime accountability
For much of its history, identity governance has focused on employees, contractors, partners and service accounts. Access certifications, audit preparation and manual reviews can identify excessive privilege, but they generally happen after access has existed for some time.
At Navigate 2026, SailPoint argued that human and non-human identities should be connected through one policy context. An agent may act for a person, a team or another agent, but its authority still needs a traceable owner. The useful concept is not a separate inventory of bots. It is a chain of delegated responsibility.
An agent without a clear owner is not merely a technical asset. It is delegated business authority with unclear accountability.
The source article reported that SailPoint’s research found 79% of surveyed organisations run AI agents in production, while 2% use identity security tools to govern them and 15% can provision non-human access in real time. The keynote also cited a ratio of 109 non-human identities for every human identity.
Figures mentioned are company-reported and indicative; definitions, sample composition, methodology and operating conditions may affect how they apply to a specific organisation.
The hidden insight is that AI did not create weak access governance. It increases the cost of leaving it unresolved. A dormant service account was already a control gap. An agent that can use that account, interpret instructions and call several systems turns the same gap into an operational workflow risk.
Why machine-speed activity changes the control point
SailPoint described an average Global 2000 company seeing between 75 million and 150 million agentic interactions per day. The keynote also referred to scenarios involving up to 10,000 tool calls per second. Those figures are not universal benchmarks, but they illustrate the mismatch between automated execution and manual approval.
Figures mentioned are indicative and may vary according to architecture, workload, organisation size and the definitions used in the source research.
Internet operations provide a useful historical precedent. As software and traffic moved faster, teams shifted from manually inspecting every event to combining policy rules, automated detection and targeted human investigation. The principle was not that people became irrelevant. It was that people moved upstream, defining controls and handling exceptions while machines enforced repeatable decisions.
The same pattern applies to identity. Human review remains valuable for policy design, sensitive approvals and investigations. It is poorly suited to approving every tool call made by a growing population of agents.
This also explains why a generic kill switch is incomplete. If a runtime control cannot distinguish an authorised action from a compromised or misconfigured one, it may stop legitimate and harmful activity together. The business may then weaken or bypass the control. Identity, purpose and context determine whether intervention is precise enough to remain operationally useful.
A practical access framework for AI agents
Before buying another security product, map the authority already held by your agents. Apply the following checklist to one consequential workflow first, such as customer-data retrieval, invoice approval or production deployment.
Ownership: Can the agent be tied to a named person, team or controlled parent system?
Purpose: Is its permitted action narrow enough to describe in business terms?
Lineage: Can you trace the path from human intent to agent decision, tool call and resulting change?
Runtime response: Can policy pause, reduce or revoke access when behaviour deviates from the approved purpose?
Recovery: Can operators remove the affected credential without taking unrelated workflows offline?
A common mistake is to start with prompt engineering. Better instructions may reduce some failure modes, but they do not establish authorisation. Another mistake is to treat every agent as an isolated security category. That can hide the human or system that delegated the authority.
The output of this exercise should be concrete: a named owner, a permission boundary, an approved tool list, an action trail and a recovery procedure. If engineers cannot implement the policy and auditors cannot understand it, the design is not ready for wider deployment.
Where product teams should build
The opportunity is not simply another agent directory. It is the decision layer connecting identity, permissions, tool calls and business context.
That layer may include discovery of unapproved agents, credential lineage, runtime authorisation, policy-aware redaction and selective deprovisioning. It may also need connections to network proxies, endpoint controls, data-security tools and existing identity systems. The trade-off is complexity: broader integration can improve coverage, while also increasing policy conflicts, latency and maintenance work.
Penetration testing can reveal whether an agent reaches resources it should not, but a test report does not create a runtime control. Reinforcement learning may change how an agent selects actions, but it does not establish who is accountable for those actions. Security design has to cover both model behaviour and delegated authority.
The control also belongs in the ci cd pipeline. New tools, scopes and service identities should be reviewed before deployment, with ownership and rollback paths recorded alongside application changes. This need not block experimentation. It makes authority changes visible before they become permanent dependencies.
How founders and buyers should evaluate the category
Founders should treat identity context as a product requirement whenever agents can touch customer records, money, infrastructure or sensitive workflows. A strong initial design is usually narrow: one owner, one purpose, minimum necessary permissions, explicit tool boundaries and an auditable action trail.
Buyers should compare systems using decision criteria rather than feature counts. Ask whether the control can identify the initiating person or system, evaluate the requested action against policy, enforce the decision before execution and respond selectively when risk changes.
Also ask what happens when an identity provider, policy engine or integration is unavailable. A design that fails closed may interrupt legitimate work. A design that fails open may permit activity outside the intended policy. The appropriate choice depends on the workflow, its recovery process and its tolerance for interruption.
What caught my attention in the keynote discussion was the emphasis on accountability rather than visibility alone. A dashboard can show that an agent acted. It cannot, by itself, establish whether the action was authorised or what business owner should answer for it.
For further operating-design analysis, explore the Yanisa Execution blog and compare the control model with the workflows your team is actually deploying.
What computer vision means in this access-control discussion
People searching for “computer vision” may simply be looking for how different AI systems should be governed. The answer is that the modality is secondary: image, text and structured-data systems all need ownership, purpose, permission boundaries and traceable actions.
The practical direction from SailPoint’s keynote is therefore clear. Connect people, agents, credentials and actions in one policy model, then automate only the decisions that are sufficiently well defined to enforce safely in context.
When software acts at machine speed, accountability has to travel with the action.
If you are assessing this transition, review one high-value workflow, document its identity chain and compare enforcement options before expanding deployment. You can also read more from Yanisa Execution on AI, automation and operating design.
Frequently Asked Questions
Why are periodic access reviews not enough for AI agents?
Periodic reviews can identify excessive or outdated access, but an agent may make many tool calls between review cycles. Organisations may therefore need policy checks and selective enforcement closer to the time of each consequential action.
Should human and AI agent identities be managed together?
They may require different technical controls, but separating them completely can obscure accountability. A useful model links each agent to the person, team or parent system that delegated its authority.
Is an agent kill switch enough to secure an AI workflow?
A kill switch can help during an incident, but it may be too broad if it cannot distinguish legitimate activity from harmful activity. Selective revocation depends on identity, purpose, permissions and runtime context.
What should companies check before deploying an AI agent?
They should review ownership, permitted tools, data access, credential lineage, approval boundaries, logging and recovery procedures. They should also decide how the workflow behaves if a policy service or identity dependency becomes unavailable.
How can founders design safer AI agent products?
Start with a narrow workflow, assign explicit ownership and grant only the permissions needed for that task. Build traceability, policy enforcement and revocation into the product rather than treating them as later additions.