AI Agent Security for Organisations Already Using Okta

AI agents are entering enterprise environments through the tools employees already use: SaaS apps, productivity suites, developer platforms, CRM systems, service desks and internal workflows.

Organisations already using Okta need to consider which agents are connected, what have users approved, which systems can they reach, and how quickly can access be removed.

Okta’s AI at Work 2025 research reports that 91% of organisations are already using AI agents, while only 10% have a well-developed strategy for managing these non-human identities. That gap matters because AI agents can use APIs, analyse data and take actions on behalf of users without direct human intervention.

For CISOs, CTOs and IAM leaders, the priority is to bring AI agents into the same identity controls already used for people, applications and other non-human identities.

Okta is a logical place to start.

AI agents are identities

Security teams have spent years improving identity controls for employees, partners, administrators, contractors, service accounts and applications. AI agents now need the same discipline.

Okta describes AI agents as a form of non-human identity, alongside devices, applications, services and automated processes. Its AI at Work 2025 guidance states that these identities require IAM rigour, governance and guardrails.

Existing Okta environments give organisations a head start.

Many companies already use Okta for SSO, MFA, lifecycle management, directory services, access policies, logs and application integrations. The next move is to extend those controls to agents that operate across SaaS apps, APIs, cloud services and internal tools.

Okta’s Govern AI agent identity page reduces the problem to 3 questions: where are my agents, what can they connect to, and what can they do? Those questions are a useful operating model for any organisation with Okta already installed.

The first risk is visibility

Most AI-agent risk starts with limited visibility.

An employee may connect an AI assistant to Google Workspace. A developer may connect an agent to GitHub. A business team may test a SaaS agent with Salesforce or ServiceNow access. Each connection may create OAuth grants, tokens, scopes or permissions that security teams didn’t approve.

Okta’s Agent Discovery announcement focuses on this shadow AI problem by detecting OAuth consents and identifying unknown agents, their connected applications and their permissions.

For Okta customers, the first workstream should be discovery:

1. Review OAuth grants.
2. Identify connected AI tools.
3. Map which apps, APIs and data sources each agent can reach.
4. Separate approved agents from experiments.
5. Revoke unused or unknown grants.
6. Prioritise systems such as Microsoft 365, Google Workspace, GitHub, Slack, Salesforce, Jira, ServiceNow, cloud consoles and security tools.

This gives security leaders the inventory they need before policy design begins.

Assign owners to every agent

A human user has a manager, a role, a department and a lifecycle. AI agents need the same accountability model.

That creates audit and accountability problems. If an agent accesses sensitive data or changes a workflow, security teams need to know which person, team or business process stands behind that action.

Okta’s Okta for AI Agents is now generally available and includes the ability to discover, onboard, protect and govern AI agents. It also supports access reviews, approval workflows, audit logs, telemetry and deactivation.

For an Okta customer, every AI agent should have a clear record:

1. Human owner;
2. Technical owner;
3. Business purpose;
4. Connected systems;
5. Data classification;
6. Permission scope;
7. Lifecycle status;
8. Expiry date for temporary use cases.

This turns an unknown agent into a governed identity.

Replace standing access with scoped access

AI agents should not inherit broad access because they act on behalf of a user or team. Their permissions should match the specific task.

Okta for AI Agents can replace hardcoded credentials and standing access with scoped, short-lived tokens issued for the required action and time window. This is a practical control point.

An HR agent that answers employee policy questions should not export full employee records. A support agent that retrieves order status should not refund transactions without approval. A developer agent that reads documentation should not change production repositories. A security agent that opens investigation notes should not disable controls without a higher-trust workflow.

Least privilege should cover data, tools and actions.

Start with read access. Add write permissions only where justified. Require approval for admin, delete, export, payment, privilege change, production change and security-control actions. Apply shorter expiry windows for agents connected to sensitive data or regulated workflows.

Govern agent-to-app access

Agentic systems often need to act across multiple applications. A customer support agent may read a CRM record, check an order system, draft a response and open a ticket. A developer agent may read a repository, search documentation and propose a pull request.

This requires governed app-to-app and agent-to-app access.

Okta’s Cross App Access developer guidance describes a model with a requesting app, a resource app and a managed connection controlled through Okta. Okta’s AI agent token exchange guide also covers credentials such as secrets, service accounts and third-party access tokens for protected resources.

Agent access should run through managed identity flows, approved connections and visible policy controls. Shared credentials, embedded secrets and uncontrolled tokens should be removed from agent workflows.

Keep Auth0 in scope for custom agents

Some organisations will use vendor-provided agents. Others will build internal or customer-facing agents.

For custom agents, Auth0 becomes relevant. Auth0 for AI Agents includes User Authentication, Token Vault, Async Authorization and Fine-Grained Authorization for RAG.

This article focuses on Okta governance. The deeper CIAM architecture patterns sit in the companion Auth0 article: agent identity, delegated access, token exchange, consent, Token Vault, fine-grained authorization and MCP.

For Okta customers, the important point is that custom agents should still be registered, owned, scoped, reviewed and monitored through the identity programme.

That matters for customer identity, employee knowledge assistants and B2B portals. Retrieval must respect the user’s actual permissions.

Include agents in governance and audit

Access reviews should include AI agents.

Owners should certify purpose, scope, connected apps, data access, privilege level, expiry and recent activity. Dormant agents should be removed. Agents with access to customer data, financial systems, production infrastructure or security tooling should be reviewed more frequently.

Okta’s Okta for AI Agents GA announcement includes automated access reviews, structured approval workflows, audit trails, SIEM telemetry and an agent kill switch.

Security operations should also receive agent identity events:

1. Token requests;
2. Denied actions;
3. Unusual scopes;
4. New app connections;
5. Privilege changes;
6. Failed policy checks;
7. Deactivation events.

This evidence matters for audits, investigations and incident response.

Test the risk

AI-agent security also needs validation.

The OWASP Top 10 for Agentic Applications 2026 covers risks for autonomous systems that plan, act and make decisions across workflows.

Cobalt’s State of Pentesting 2025 findings show that LLM pentests produced the highest proportion of serious vulnerabilities, at 32%, and only 21% of serious vulnerabilities discovered in LLM tests were resolved.

Identity controls give security teams stronger governance over AI agents. Testing should cover agent behaviour, prompt injection, excessive permissions, tool misuse, data exposure and approval bypasses.

A practical 90-day path

A 90-day plan for Okta customers should focus on control before scale.

In the first 30 days, build visibility. Review OAuth grants, connected apps, AI tools, API permissions and privileged integrations. Identify unknown agents and revoke access that has no owner or business reason.

In days 31 to 60, assign ownership and scope. Register approved agents, document business purpose, classify connected data, define permission boundaries and apply expiry dates for temporary use cases.

In days 61 to 90, add governance. Include agents in access reviews, route high-risk actions through approvals, send agent events to security operations, define deactivation workflows and test high-risk agents before expanding access.

Identity is the control point

AI agents will become part of enterprise operations. Some will assist employees. Some will support customers. Some will operate inside IT, security, finance, HR and development workflows.

For organisations already using Okta, the path is clear: discover agents, register them as identities, assign owners, govern access, monitor activity and revoke permissions when needed.

The companies that move first will give security leaders a defensible way to adopt AI while keeping accountability, auditability and trust in view.