Skip to main content
AI activity often appears under different identities: a work email, a personal account, a device, a provider identity, or an agent principal. Oximy resolves those source aliases to stable people, agents, applications, and groups.

Workspace boundary

A workspace is the customer boundary for data, configuration, integrations, policies, and product access.

People and organization

People can be associated with departments, managers, devices, accounts, and observed activity. Organization structure supports department reporting and, where configured, manager-scoped visibility.

Identity resolution

Each source identifier enters the identity graph with its source, type, confidence, and authority. Higher-authority administrative and provider facts take precedence over lower-confidence automated matches. Unresolved activity is retained as unattributed rather than discarded. An administrator can review identity proposals, map a device or account to the correct person, or explicitly leave an alias unattributed.

Account classification

Visibility can distinguish organization-managed accounts from personal or shared accounts when the available signals support that attribution. This helps separate official adoption from shadow usage and credential-sharing risk.

Agents and service identities

Agent activity should not be attributed to a human solely because it used that person’s credential or device. Oximy models agent and service principals separately where the source provides enough context.

Device enrollment

Device enrollment uses the same identity model. A device can be bound through self-enrollment, an imported roster, an identity provider, MDM-supplied information, or an administrator decision. MDM is one signal, not a requirement for attribution.

Access controls

Product and administrative access should follow least privilege. The effective controls depend on the configured identity provider, product modules, roles, and deployment. During implementation, define:
  • Who administers the workspace.
  • Which teams can view organization-wide or department-level data.
  • Who can manage integrations, provider keys, routing, and policies.
  • Which actions require approval.
  • How access is removed when a person changes role or leaves.
Authentication and provisioning are configured for the selected deployment. Document SSO, SCIM, role, and lifecycle requirements as part of the implementation.
Identity resolution and authorization solve different problems. The identity graph determines who or what produced activity; access controls determine who may view data or perform an action.