> ## Documentation Index > Fetch the complete documentation index at: https://oximy.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Identity and access > How Oximy connects people, accounts, devices, departments, and agent principals. 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.