Identity Security Insights 26.08.1

Your Okta org is a lot more than users and groups; it's admin roles, API tokens, federation trusts, and policies, all quietly shaping who can do what. Insights now brings much more of that into the identity graph, nearly doubling Okta coverage with five new entity types and fifteen new relationships. The result: attack paths and entitlements that better reflect how Okta actually grants power, not just who's in which group.

What you get with this update

• Admin blast radius, resolved precisely: Every standard and custom admin role now traces down to the exact apps, groups, and users it can manage. Super and Org admins fan out to everything in the tenant; scoped admins (App, User, Help Desk, Group Membership) resolve only to their actual targets, and custom roles resolve through the resource sets that bound them. Three new entitlements answer the questions that matter in an access review: who can manage this app, this group, this user; reported separately from plain app assignment, so admin reviews and assignment reviews never blur together.
• API tokens as first-class identities: Active Okta API tokens now appear in the graph, each linked to the user whose privileges it carries. A token in the wrong hands is that user. A new entitlement surfaces exactly which accounts each token can act as, so long-lived tokens tied to over-privileged admins stop hiding.
• Federation trust, made visible: External identity providers (SAML, OIDC, social) are now mapped to the users they provision, flagged as trust boundaries. When an upstream IdP is compromised, you can see the identities in your org it can mint or take over.
• Policy coverage you can trace: Sign-on, password, and MFA enrollment policies now connect to the groups they govern, and authentication and profile enrollment policies connect to their apps -- so you can follow a policy straight to everything it protects (and spot what it doesn't).
• The quieter privilege paths: Group ownership (users or groups that own other groups) and app-to-authorization-server relationships -- including servers open to every client in the tenant -- are now in the graph, shrinking the blind spots where escalation paths hide.

🚧

Important

This update requires additional Okta API permissions for your Insights integration: okta.authenticators.read, okta.devices.read, and okta.trustedOrigins.read. Grant these to your existing Okta connection to ensure uninterrupted data collection.

AgentCore gateways, tokens, and identities join the attack path

AI agents don't ask for permission the way people do. They hold tokens, call gateways, and borrow the privilege of whatever identity spun them up. Insights now brings the identity layer of Amazon Bedrock AgentCore into the graph and connects it to the IAM principals, Okta apps, and Entra ID applications on either side.

What you get with this update

• Your AgentCore estate, connected: Gateways, gateway targets, workload identities, and OAuth2 credential providers are now graph entities, wired the way AWS runs them
  • Gateway to target
  • Target to the Lambda or agent runtime it fronts
  • Gateways and runtimes to the workload identities they act as
    Each runtime version is its own non-human identity, so a version with a new execution role doesn't quietly overwrite what you reviewed last quarter.
• Who can steal your agents' OAuth tokens: Insights shows which IAM users, roles, Bedrock agents, and agent runtimes can retrieve tokens from a credential provider. Coverage spans inline, customer-managed, and AWS-managed policies, including wildcard grants.
  They surface as secret entitlements, so a provider reachable by a broad developer role reads as what it is: a shared secret with too many owners.
• Who can reach your gateways: IAM-authorized gateways resolve to every principal allowed to invoke them. Gateways fronted by Okta or Entra ID instead link to the apps allowed to call them, with entitlements for which Okta and Entra ID users get through. Inbound access is answered by whichever control actually governs it.
• Escalation that crosses clouds: AWS IAM users, roles, Bedrock agents, and agent runtimes now trace through to Okta admin roles and Entra ID service principals, plus Okta and Entra ID to each other. An agent that authenticates as an IdP app and lands on an admin role stops disappearing between two consoles.