SaaS
Every connected app is an identity.Most are unowned.
OAuth grants, connected apps, bot tokens, integration users and domain-wide delegation give third parties and internal tools standing access to your mail, files, customers and tickets. No SaaS connector ships yet. The ownership model, posture policies and identity graph that would govern these grants are built, and SaaS grants join them when a connector does.
No connector in this category has shipped yet · available today: AWS IAM · Kubernetes · HashiCorp Vault · GitHub · Model Context Protocol
SaaS identity types
The identities that live inside your SaaS
They were created with a click, they authenticate with a refresh token, and they outlive the person who approved them.
OAuth & connected apps
Third-party and internal apps with delegated or application-level scopes, refreshing tokens long after anyone remembers installing them
Bots & integration users
Bot tokens, integration users and service accounts that live inside SaaS tenants with their own permissions
API tokens
Personal and service API tokens for ITSM, CRM, wikis and ticketing — often created by one person for a whole team
Domain-wide delegation
Service accounts and apps that can impersonate every user in the domain, granted for a single integration
SaaS risks
Where SaaS access quietly accumulates
Six failure patterns specific to SaaS identities and where each stands — no SaaS connector ships yet, so none is surfaced today.
Domain-wide delegation
Planned signalApps and service accounts that can impersonate any user, the scopes they hold and the integration that justified them
Unowned OAuth apps
Planned signalApps installed by people who have left or changed roles, still refreshing tokens and reading data
Over-scoped grants
Planned signalRead-all-mail, full-drive or full-CRM scopes for apps that need one object type
Shadow AI integrations
Not surfaced, by designAI assistants that arrive through OAuth consent are not discovered as agents — no connector discovers an agent, by design
Shared integration users
Planned signalOne integration user reused by several vendors and scripts, so nobody can be revoked alone
Tokens without expiry
Planned signalAPI tokens created years ago with no rotation, no owner and standing access to tickets or customers
How it works
Inventory the grants. Own them. Translate scopes into data.
Three moves SaaS governance needs: find every grant and token, attach each to an owner, and turn scope strings into the data they expose. The ownership and graph machinery is built; the SaaS connectors that would feed it are not yet.
Installed by a person. Governed by a team.
An OAuth app's installer is rarely its owner. Trustivan's ownership model — declared, inferred or unknown, resolved to a user or team and assignable by a person — already governs every identity the shipping connectors report. SaaS grants enter the same model when a SaaS connector ships; none does yet.
- Ownership states declared, inferred or unknown — a hint is never stored as an owner.
- Offboarding from a directory needs an identity-provider connector, which is a future capability.
- Unowned identities raise findings instead of becoming a permanent exception.
A scope string is a claim. The data it reaches is the risk.
mail.readonly, full, admin.directory.user — scopes are shorthand for data. Reading each grant as the objects and records it reaches, so a broad scope on the finance drive outranks ten narrow ones on empty sandboxes, is how SaaS risk should be read. The graph that computes reach for AWS and Kubernetes identities today is where that translation will land.
- Scope catalogs per platform mapped to object types — a future capability.
- Delegation and impersonation rendered as reach over users, not as a checkbox — a future capability.
- Reach on the graph today for every identity the shipping connectors report, as an upper bound.
The AI assistant your users connected last week is a SaaS identity
AI assistants and agents arrive through the same OAuth consent screens as any other app — with scopes on mail, files, chat and customer records. No connector discovers an agent, and no screen registers one; that is a refusal by design, not a gap on a roadmap. What Trustivan governs is the agent identity a deployment holds: its owner, its autonomy, its tool entitlements and every action it asks the runtime gate to take.
- AI apps are not recognized from publishers or scopes: inferring an agent from strings is exactly the guess the product refuses.
- Unprofiled agents are flagged when an agent identity exists without a profile.
- Agent governance with tool entitlements and runtime authorization is available today.
Integration coverage
Collaboration, CRM, ITSM and identity connectors, labelled honestly
Platform names are used nominatively. No SaaS or identity-provider connector ships yet; each name here is planned.
View all integrations- Active DirectoryService accounts, gMSAs, SPNs, delegationPlanned
- Atlassian Jira & ConfluenceAPI tokens, OAuth apps, service accountsPlanned
- Google WorkspaceOAuth apps, domain-wide delegation, service accountsPlanned
- Microsoft 365App consents, mailbox delegations, Graph permissionsPlanned
- Microsoft Entra IDEnterprise apps, OAuth consents, credentials, ownersPlanned
- NotionIntegrations, tokens, shared pagesPlanned
- OktaApplications, API tokens, service users, OAuth grantsPlanned
- Ping IdentityOAuth clients, applications, grantsPlanned
- SalesforceConnected apps, integration users, OAuth tokensPlanned
- ServiceNowIntegration users, OAuth apps, ticket workflowsPlanned
- SlackApps, bot tokens, scopes, installersPlanned
- WorkatoConnections, recipes, service identitiesPlanned
- ZendeskAPI tokens, OAuth clientsPlanned