# Identity & privileged access: enterprise AI policy pack Let agents assist with access administration while ensuring they cannot expand their own authority, create standing privileged access or weaken authentication controls. Implementation guidance, not executable Tracelet configuration or legal advice. Tool names identify places where the control may apply; they do not claim shipped connector coverage. Confirm actual tool/action coverage and enforce destination permissions. Replace example thresholds, IDs and approval windows with your approved values. ## Control scope - Protected assets: Users, groups, roles, policies, service principals, workload identities and authentication controls - Consequential actions: Privilege grants, self-modification, credential creation, MFA/SSO changes and bulk lifecycle operations - Applicable systems: Microsoft Entra ID, Okta, Google Workspace, AWS IAM, Azure RBAC, Google Cloud IAM and GitHub - Context to resolve: Resolve the actor and effective identity, target principal, resulting permissions, scope, duration, approver and conflicts before mutation. - Enforcement boundary: Keep protected identity administration outside the agent credential. Use PIM/JIT, policy conditions, approval workflows and immutable audit events at the identity provider. ## Owners Identity platform owner + security operations ## Configure first - Privileged roles, protected groups, break-glass accounts and control-plane identities - Eligible approvers, maximum access duration, ticket requirements and segregation-of-duties conflicts - Approved workload identity patterns, credential stores and key-expiry limits ## Shared decision baseline ### Resolve the real target Decide on immutable IDs and effective context: principal, tenant/account, environment, resource, data classification and destination. Names and local profiles are hints, not authority. ### Fail closed on consequential ambiguity If the target, blast radius, tenant or data classification cannot be resolved, hold the action. Do not treat missing metadata as non-production or low risk. ### Bind approval to the exact action An approval covers the actor, operation, target set, content or artifact digest, value and expiry. Material changes invalidate it; the requester cannot approve their own action. ### Keep an evidence-grade decision record Record resolved context, policy version, matched rule, decision, approver and downstream result. Minimise captured sensitive content and protect the record from the acting identity. ## Policies ### IA-01: Block agent self-escalation and guardrail modification - Severity: Critical - Decision: Block - Owner: Identity security owner #### Policy statement Deny an agent or its acting principal from changing its own roles, group membership, permission boundary, trust policy, credentials, policy controls or audit configuration. #### Covered operations - Attach policy or add actor to a privileged group - Change role trust, permission boundary or service-principal ownership - Disable or edit the policy that is evaluating the action #### Evaluation rules - Resolve the effective principal across impersonation, assumed roles, service principals and delegated credentials. - Compute resulting permissions and transitive group/role inheritance rather than matching role names. - Correlate multi-step escalation paths such as create role, alter trust, assume role. #### Example decisions (illustrative; do not run against live systems) - **AWS IAM:** `Attach AdministratorAccess to the current agent role`. Block. - **Microsoft Entra ID:** `Add the agent service principal as an owner of a privileged app`. Block. #### Applicable tools and systems - AWS IAM - Microsoft Entra ID - Google Cloud IAM - Okta - Google Workspace - GitHub Enterprise - Kubernetes RBAC #### Enforcement Apply immutable permission boundaries and keep identity administration in a separate brokered role. Evaluate effective access before mutation and protect policy administration from the acting identity. #### Exception / approval None. Any access expansion must be executed by a different, authorised identity after independent review. #### Test fixtures - Should remain permitted: Read the actor’s effective access or request a separately approved temporary role through the authorised workflow. - Should be blocked or held: Grant itself access directly or via a group, change its trust policy or disable the control that would block it. #### Implementation references - [AWS · Service control policies](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) - [Google Cloud · IAM deny policies](https://cloud.google.com/iam/docs/deny-overview) ### IA-02: Keep tier-zero and organisation-wide administration out of agent scope - Severity: Critical - Decision: Block - Owner: Tier-zero identity owner #### Policy statement Deny direct or standing grants of global, organisation, root, billing, identity-provider, key-administrator and equivalent tier-zero roles to agents or through agent-managed identities. #### Covered operations - Grant global/organisation administrator or owner - Add to protected tier-zero group - Assign permanent privileged eligibility without activation controls #### Evaluation rules - Maintain protected permissions by effective capability and scope, not only built-in role names. - Detect custom roles and nested groups that confer equivalent control-plane authority. - Keep break-glass accounts excluded from automation and require human-held phishing-resistant authentication. #### Example decisions (illustrative; do not run against live systems) - **Microsoft Entra ID:** `Assign Global Administrator to agent-app`. Block. - **Google Cloud:** `Grant roles/resourcemanager.organizationAdmin to an automation principal`. Block. #### Applicable tools and systems - Microsoft Entra ID - Okta - Google Workspace - AWS Organizations / IAM - Google Cloud IAM - Azure RBAC - GitHub Enterprise #### Enforcement Exclude tier-zero actions from routine agent credentials and require a hardened privileged-access workstation and JIT workflow for authorised humans. #### Exception / approval No agent exception. Break-glass use is human-only, separately monitored and reviewed immediately after use. #### Test fixtures - Should remain permitted: Request a narrowly scoped, time-bound operational role through PIM/JIT. - Should be blocked or held: Grant a tier-zero role directly, via a custom role or through nested protected-group membership. #### Implementation references - [Microsoft Entra · Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) - [NIST SP 800-207 · Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) ### IA-03: Require scoped, time-bound approval for privileged access - Severity: High - Decision: Require approval - Owner: Resource owner #### Policy statement Hold any non-tier-zero privileged grant unless it is limited to the minimum resource scope and permissions, has an approved duration and names a valid business or incident reason. #### Covered operations - Assign privileged role or group membership - Activate eligible access - Delegate application, database, repository or cloud administration #### Evaluation rules - Calculate effective permissions and segregation-of-duties conflicts after the proposed grant. - Require a resource owner who is neither requester nor target principal; bind approval to scope, permissions and expiry. - Reject permanent grants when an eligible/JIT mechanism exists and revoke automatically at expiry. #### Example decisions (illustrative; do not run against live systems) - **Azure PIM:** `Activate Contributor on subscription prod for 60 minutes`. Hold for configured approver and reason. - **AWS IAM Identity Center:** `Assign database-admin permission set to one production account`. Hold and expire automatically. #### Applicable tools and systems - Microsoft Entra PIM - AWS IAM Identity Center - Google Cloud IAM - Okta - Teleport - CyberArk - HashiCorp Boundary #### Enforcement Use the identity platform’s JIT/PIM mechanism and short-lived credentials. The agent may prepare the request but must not mint or activate the privileged session itself. #### Exception / approval Emergency access requires the incident identifier and an approved break-glass path; it expires quickly and triggers retrospective review. #### Test fixtures - Should remain permitted: Activate an approved, exact role on one resource for the approved duration. - Should be blocked or held: Broaden scope, extend expiry, change role after approval or reuse the approval for another principal. #### Implementation references - [Microsoft Entra · Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) ### IA-04: Block weakening of authentication and session controls - Severity: Critical - Decision: Block - Owner: Authentication platform owner #### Policy statement Deny agent changes that disable or bypass required MFA, SSO, conditional access, device trust, session lifetime or phishing-resistant authentication for protected users and applications. #### Covered operations - Disable MFA/SSO or create a bypass group - Exclude privileged users or apps from conditional access - Extend session/token lifetime or weaken authentication method policy #### Evaluation rules - Evaluate the resulting policy including exclusions, group nesting, emergency accounts and application coverage. - Correlate staged edits that create a bypass even when each edit appears narrow. - Block changes affecting privileged or broad populations; unknown population size fails closed. #### Example decisions (illustrative; do not run against live systems) - **Okta:** `Exclude Engineering-All from the phishing-resistant MFA rule`. Block. - **Microsoft Entra ID:** `Set conditional-access policy state to disabled`. Block. #### Applicable tools and systems - Microsoft Entra ID - Okta - Google Workspace - Duo - Ping Identity - Auth0 - AWS IAM Identity Center #### Enforcement Keep authentication policy administration outside agent roles and use provider protections plus configuration monitoring. Send tamper events to a security-owned audit destination. #### Exception / approval A security-led outage procedure may use narrowly scoped, expiring exclusions with compensating monitoring; agents cannot approve or execute it alone. #### Test fixtures - Should remain permitted: Add a stronger authentication method or narrow a temporary test exclusion in a sandbox tenant. - Should be blocked or held: Disable the policy, add a broad bypass, remove device trust or extend privileged sessions beyond the baseline. #### Implementation references - [NIST SP 800-207 · Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) ### IA-05: Review bulk user suspension, deletion and access revocation - Severity: High - Decision: Require two-person approval - Owner: Identity operations + business owner #### Policy statement Hold bulk identity lifecycle actions that can lock out a team, customer population or privileged operating group, including correlated single-user requests above the configured threshold. #### Covered operations - Suspend, deactivate or delete users - Remove group memberships or application assignments in bulk - Reset sessions or credentials for a broad population #### Evaluation rules - Expand groups and selectors to exact principals and identify protected, break-glass and service identities. - Aggregate by actor and time window to detect split batches; fail closed when population cannot be determined. - Require identity operations and business owner approval for the exact principal list and lifecycle action. #### Example decisions (illustrative; do not run against live systems) - **Google Workspace:** `Suspend all users matching department=Sales`. Hold and expand the exact population. - **Okta:** `Deactivate 250 imported users`. Hold for two-person approval. #### Applicable tools and systems - Microsoft Entra ID - Okta - Google Workspace - OneLogin - HRIS provisioning - SCIM integrations - GitHub Enterprise #### Enforcement Use a lifecycle broker with dry-run population expansion, protected-identity exclusions, dual approval and a recovery plan. Preserve the exact subject list in the decision record. #### Exception / approval Incident containment can use a security-approved population and short-lived session revocation; permanent deletion waits for normal review. #### Test fixtures - Should remain permitted: Disable one verified departed user through the normal HR-driven workflow. - Should be blocked or held: Disable a broad group, include a break-glass account or split a mass deactivation into small batches. #### Implementation references - [Microsoft Entra · Privileged Identity Management](https://learn.microsoft.com/en-us/entra/id-governance/privileged-identity-management/pim-configure) ### IA-06: Block unmanaged long-lived credentials - Severity: High - Decision: Block - Owner: Workload identity owner #### Policy statement Deny creation, export or disclosure of long-lived keys, client secrets, tokens and passwords for agent use when a managed workload identity or short-lived credential is available. #### Covered operations - Create access key, client secret, personal token or service-account key - Return secret material in chat, logs or files - Set expiry beyond the approved maximum or disable rotation #### Evaluation rules - Identify credential type, principal, scopes, expiry, destination and whether federation/workload identity is supported. - Never return secret values to conversational output or an unapproved workspace, even when creation itself is authorised. - Block broad or non-expiring credentials and credentials owned by shared human accounts. #### Example decisions (illustrative; do not run against live systems) - **Google Cloud IAM:** `Create a downloadable service-account JSON key`. Block for routine agent use. - **GitHub:** `Create a classic PAT with repo and admin:org scopes`. Block. #### Applicable tools and systems - AWS IAM / STS - Microsoft Entra workload identity - Google Cloud IAM - GitHub - GitLab - Kubernetes - HashiCorp Vault #### Enforcement Prefer OIDC/workload federation and brokered short-lived tokens. Use organisation policy to prohibit key creation and secret scanners to detect disclosure at adjacent channels. #### Exception / approval A documented legacy-system exception requires minimum scope, short expiry, managed-vault delivery and an accountable rotation owner. #### Test fixtures - Should remain permitted: Obtain a short-lived, audience-bound token through the approved workload identity flow. - Should be blocked or held: Create a non-expiring key, write a secret into the repository or print returned secret material into agent output. #### Implementation references - [NIST SP 800-207 · Zero Trust Architecture](https://csrc.nist.gov/pubs/sp/800/207/final) ## Rollout checklist - [ ] Inventory authoritative resource IDs, environments, classifications and owners. - [ ] Map every entry point: IDE, agent, CLI, MCP, API, browser and direct console. - [ ] Put the hard deny or least-privilege boundary in the destination system. - [ ] Test permitted, held and denied fixtures using synthetic data in a sandbox. - [ ] Test aliases, APIs, batch operations, changed approvals, retries and unknown scope. - [ ] Observe matches, tune false positives and then enforce a bounded production scope. Coverage: https://tracelet.ai/platform#coverage