Skip to main content
Live

43,280 AI events recorded on our own engineering fleet in the last 30 days.

Enterprise AI policy library

Set the rules.Before AI acts.

Practical policies for the actions you can’t afford to get wrong. Protect production data, privileged access and business decisions with clear, reviewable controls.

A policy in practicePD-01 / Production data

Give agents access.
Keep destructive actions out.

Example request PostgreSQLDROP TABLE public.orders CASCADE
Resolved environment
Production
Operation
Destructive DDL
Block the action

Production data cannot be dropped or truncated.

Read-only queries remain permitted.

Read the complete policy
control domains
9
enterprise policies
51
Evaluation rulesTest casesMarkdown downloads
Choose the risk

Start with what must not go wrong.

01

Production data & databases

Prevent irreversible production data loss and unsafe, high-blast-radius changes.

5 policies · 24 systemsOpen control policies
02

Cloud & infrastructure

Stop agents from removing production foundations, exposing networks or disabling guardrails.

6 policies · 35 systemsOpen control policies
03

Identity & privileged access

Prevent privilege escalation, control-plane lockout and unmanaged credentials.

6 policies · 26 systemsOpen control policies
04

Sensitive data movement

Keep secrets and regulated data inside approved tenants, regions and recipients.

6 policies · 37 systemsOpen control policies
05

Software delivery & supply chain

Protect source controls, build trust and production releases from agent-driven changes.

6 policies · 37 systemsOpen control policies
06

Shadow AI tooling

Close every unmanaged link in the shadow AI supply chain: personal accounts, extensions, IDE assistants, MCP connectors, public models and vendor AI features.

7 policies · 42 systemsOpen control policies
07

Payments & financial operations

Separate preparation from authority to move money, alter payees or rewrite financial records.

5 policies · 21 systemsOpen control policies
08

Customer actions & communications

Control public sends, customer-impacting changes and commitments made on the company’s behalf.

5 policies · 26 systemsOpen control policies
09

Keep consequential people decisions, signatures and record disposal with accountable humans.

5 policies · 27 systemsOpen control policies
The decision baseline

Four rules behind every policy.

Apply these before provider-specific matching.

01

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.

02

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.

03

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.

04

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.

The policies

Every control, in one place.

9 control domains, 51 policies. Pick a domain from the side, filter each set by the systems you run, and download any domain as Markdown.

01 / 09 · Control domain

Production data & databases

Keep agents useful for diagnosis, query authoring and migration preparation while preventing them from destroying production data, database services or recovery paths.

5 policies24 applicable systemsOwners: Database platform owner + service ownerDownload pack .md
Control scope and what to configure first
Protected assetsProduction databases, schemas, tables, datasets, snapshots and backups
Consequential actionsDestructive DDL, service deletion, bulk mutation, recovery changes and schema migration
Applicable systemsSQL engines, cloud database services, warehouses, migration tools and database CLIs
Context to resolve
Resolve the credential, endpoint, account/project, database, schema, object, environment classification and estimated impact before deciding.
Authoritative boundary
Enforce in database privileges and cloud IAM first. Intercept agent, CLI and MCP execution for intent-aware decisions and explanations; direct consoles and SDKs need the same downstream deny.
Configure first
  • Authoritative production database, account, project and dataset inventory
  • Protected schemas and tables, criticality tier, data owner and recovery objective
  • Row-impact thresholds, approved migration runner and emergency recovery process
Policy set

Policies in this domain.

5 of 5 policies
Critical severityPD-01
01

Block destructive DDL against production data

Block
Policy statement

Deny any request that drops or truncates a production database, schema, table, collection or dataset. Unknown environment classification is treated as production for destructive DDL.

Covered operations
  • DROP DATABASE
  • DROP SCHEMA
  • DROP TABLE
  • DROP COLLECTION / DATASET
  • TRUNCATE TABLE, including CASCADE or partition-wide variants
  • Equivalent SDK, warehouse, migration-tool and admin API operations
Applicable tools & systems
PostgreSQLMySQLMicrosoft SQL ServerOracle DatabaseSnowflakeBigQueryDatabricks SQL
PostgreSQLDROP TABLE public.orders CASCADE

Block when the connection resolves to production.

BigQueryDelete dataset analytics_prod with contents

Block even when issued through an SDK or console-backed tool.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the live connection endpoint and immutable database/project identifier; do not infer safety from a local profile, alias or resource name.
  • Parse every statement in a batch, migration and stored procedure. Expand CASCADE, wildcard, selector and dependency effects before deciding.
  • Deny when any resolved target is production, protected or unresolved. Read-only introspection and EXPLAIN remain permitted.
  • Do not allow the agent that requested the action to relabel the target or disable this policy.

Enforce at

Remove destructive ownership/DDL privileges from routine agent identities and route production migrations through a controlled runner. Intercept SQL, database CLIs, migration tools and MCP calls before execution; database permissions remain the final boundary.

Exception / approval path

No self-service exception. Use a separately authenticated break-glass or approved migration workflow with backup verification and an independent operator.

Test permitted, changed and denied paths
Should remain permitted

Run SELECT, EXPLAIN and schema introspection against a permitted production database, and execute destructive DDL only in an explicitly classified ephemeral test database.

Should be blocked or held

Drop a production table, truncate a protected partition, hide DROP in a multi-statement batch, or target an endpoint whose environment cannot be resolved.

Accountable ownerDatabase platform owner
Critical severityPD-02
02

Block deletion of production database services

Block
Policy statement

Deny deletion of a production database instance, cluster, server, warehouse or account and deny changes whose purpose is to remove deletion protection immediately before deletion.

Covered operations
  • Delete database instance, cluster, logical server, warehouse or project dataset
  • Disable deletion protection, remove a protective resource lock or skip the final snapshot
  • Delete the last production replica when it eliminates service or recovery capacity
Applicable tools & systems
AWS RDS / AuroraGoogle Cloud SQL / SpannerAzure SQL / Cosmos DBMongoDB AtlasSnowflakeDatabricks
AWS RDSDeleteDBInstance(prod-orders, SkipFinalSnapshot=true)

Block.

Google Cloud SQLDisable deletion protection on orders-prod

Block as a precursor to a protected deletion.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the provider account/project/subscription, resource ID, environment tag and dependency graph from the active identity.
  • Treat protection removal followed by deletion as one sequence, including attempts split across agent turns or tools.
  • Block deletion of protected production resources regardless of final-snapshot options; a snapshot does not make unilateral deletion acceptable.

Enforce at

Enable native deletion protection or locks and deny delete/protection-change permissions to the agent principal. Protect the identity that can remove the native guardrail with a separate approval path.

Exception / approval path

A decommission workflow must verify dependency removal, recovery evidence, retention obligations and two-person authorisation; it runs outside the routine agent identity.

Test permitted, changed and denied paths
Should remain permitted

Describe configuration, create a restore drill in an approved sandbox or delete an explicitly ephemeral database instance.

Should be blocked or held

Delete a protected instance, disable its deletion protection, remove its lock or perform the same action through an API alias.

High severityPD-03
03

Review high-blast-radius production mutations

Require approval
Policy statement

Hold production DELETE, UPDATE, MERGE and overwrite operations when impact is unbounded or exceeds the data owner’s configured row, partition or percentage threshold.

Covered operations
  • DELETE or UPDATE without a selective predicate
  • MERGE, overwrite or partition replacement
  • Batch and repeated writes whose cumulative impact crosses a threshold
Applicable tools & systems
PostgreSQLMySQLMicrosoft SQL ServerSnowflakeBigQueryRedshiftDatabricks SQL
SQLUPDATE customers SET status='inactive'

Hold because the statement is unbounded.

SnowflakeDELETE FROM events WHERE created_at < :cutoff

Hold when the estimate exceeds the configured partition or row threshold.

Evaluation rules & enforcement

Evaluate these conditions

  • Use a query plan, dry run or transaction-safe estimate to calculate affected rows/bytes/partitions; never execute the write to discover its impact.
  • Hold statements without a predicate, with always-true predicates or with an unresolved estimate.
  • Aggregate related requests by actor, target and time window so a large change cannot be split below the threshold.
  • Bind approval to the query digest, resolved target set, estimated impact and short expiry.

Enforce at

Use a query gateway or controlled write role that can require an approved query digest. Apply statement timeouts, transaction controls and workload limits in the database as secondary safeguards.

Exception / approval path

One approval for the exact target, statement digest and estimated impact. Require a fresh decision if the plan, parameters or affected-row estimate changes materially.

Test permitted, changed and denied paths
Should remain permitted

Update one synthetic record by immutable primary key within delegated authority.

Should be blocked or held

Remove the predicate after approval, change the cutoff to include more partitions or split one mass update into repeated smaller requests.

Accountable ownerData owner
Critical severityPD-04
04

Block degradation of production recovery controls

Block
Policy statement

Deny agent-initiated changes that disable backups, point-in-time recovery, versioning or deletion protection, or reduce retention below the approved recovery baseline.

Covered operations
  • Disable automated backup or point-in-time recovery
  • Reduce retention or delete protected recovery points
  • Remove object versioning, immutability or recovery vault protection
Applicable tools & systems
AWS RDS / BackupGoogle Cloud SQL / Backup and DRAzure SQL / Recovery ServicesMongoDB AtlasS3 / GCS / Azure Blob
Azure SQLReduce long-term backup retention from 12 months to 0

Block.

AWS RDSSet BackupRetentionPeriod to 0 on a production DB

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the protected resource and current approved RPO/RTO baseline before evaluating a configuration diff.
  • Treat a sequence of individually small retention reductions as one change and deny the resulting non-compliant state.
  • Protect backup copies and the controls governing them with an identity independent of the production workload and routine agent.

Enforce at

Use separate backup accounts/projects, immutable storage and provider policy to deny destructive recovery changes. Alert the recovery owner on every blocked attempt.

Exception / approval path

No routine exception. A documented retention change requires records, security and service-owner review through a separately privileged workflow.

Test permitted, changed and denied paths
Should remain permitted

Increase retention or create an additional protected recovery point.

Should be blocked or held

Disable point-in-time recovery, reduce retention below policy or delete the only valid recovery copy.

Accountable ownerResilience and recovery owner
High severityPD-05
05

Review unsafe production schema migrations

Require approval
Policy statement

Hold production schema changes that can destroy data, rewrite large tables, take blocking locks, remove compatibility or run outside the approved migration mechanism.

Covered operations
  • DROP or destructive ALTER of a column, index or constraint
  • Table rewrite, blocking index build or type conversion
  • Migration execution outside the approved runner or release
Applicable tools & systems
FlywayLiquibasePrismaDjango migrationsRails migrationsTerraform database providersNative database CLIs
FlywayALTER TABLE orders DROP COLUMN legacy_total

Hold for data-owner and service-owner review.

Prisma / ORM migrationApply generated migration directly to production

Hold when it bypasses the approved release runner.

Evaluation rules & enforcement

Evaluate these conditions

  • Evaluate the migration diff and database plan, including implicit locks, rewrites, cascades and rollback viability.
  • Require expand/contract sequencing for compatibility-sensitive changes and a verified backup or rollback path.
  • Bind approval to migration digest, release, database ID and maintenance window; edited migrations require new approval.

Enforce at

Permit production DDL only to a controlled migration identity. Require plan artefacts, lock/impact checks and release approval in the deployment pipeline.

Exception / approval path

Emergency execution requires the incident commander, database owner, captured command digest and confirmed recovery point; access expires after the incident action.

Test permitted, changed and denied paths
Should remain permitted

Generate and review a migration plan or apply a reversible migration in an isolated staging copy.

Should be blocked or held

Apply a changed migration, bypass the release identity or run an unplanned destructive ALTER in production.

Accountable ownerService owner + database owner
02 / 09 · Control domain

Cloud & infrastructure

Allow investigation, planning and bounded operational work without granting an agent unilateral control over production infrastructure or organisation-wide security controls.

6 policies35 applicable systemsOwners: Cloud platform owner + infrastructure securityDownload pack .md
Control scope and what to configure first
Protected assetsCloud estates, Kubernetes clusters, networks, workloads, logging and encryption keys
Consequential actionsDeletion, destructive plans, public exposure, guardrail changes and service shutdown
Applicable systemsAWS, Azure, Google Cloud, Kubernetes, Terraform, Pulumi and Cloudflare
Context to resolve
Resolve the principal, tenant/account/project, region, resource graph, environment tags, change ticket, maintenance window and blast radius.
Authoritative boundary
Use organisation policy, cloud IAM/RBAC, resource locks, admission controls and controlled deployment identities. Agent interception complements these controls; it does not replace them.
Configure first
  • Production accounts, subscriptions, projects, clusters, regions and critical resources
  • Approved infrastructure pipelines, plan formats, maintenance windows and service owners
  • Protected logging, security, network and encryption controls with separate break-glass custody
Policy set

Policies in this domain.

6 of 6 policies
Critical severityCI-01
01

Block deletion of production estates and critical resource containers

Block
Policy statement

Deny deletion, closure or organisation departure for production accounts, subscriptions, projects, resource groups and equivalent containers that own critical workloads.

Covered operations
  • Close cloud account or remove it from the organisation
  • Delete project, subscription, resource group or folder
  • Remove the native lock, lien or organisation policy protecting that scope
Applicable tools & systems
AWS OrganizationsAzure Resource ManagerGoogle Cloud Resource ManagerTerraformPulumiCloudFormation
Google CloudDelete project payments-prod

Block.

AzureDelete resource group rg-prod-core

Block even if the group name was supplied by the agent.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve immutable organisation, account, subscription and project identifiers plus inherited environment tags.
  • Expand the resource graph and block when the container owns production resources, security controls, billing or shared networking.
  • Treat guardrail removal and subsequent deletion as a correlated sequence across tools and sessions.

Enforce at

Apply organisation-level denies, resource locks or liens and keep their removal permissions out of agent roles. Alert both the platform owner and security operations on attempted bypass.

Exception / approval path

Only a formal estate-decommission process with dependency evidence and independent authorisation; never a reusable chat approval.

Test permitted, changed and denied paths
Should remain permitted

Read inventory or delete an explicitly ephemeral sandbox container with no protected descendants.

Should be blocked or held

Delete a production scope, remove its protection or move/rename it to evade classification.

Critical severityCI-02
02

Approve the exact production infrastructure plan

Require approval
Policy statement

Require approval for a saved production infrastructure plan containing create, update, replace or delete actions. Approval applies to the plan digest, not to a generic apply command.

Covered operations
  • terraform apply / destroy
  • pulumi up / destroy
  • CloudFormation, ARM/Bicep or deployment-manager changes
  • Equivalent provider API changes generated from infrastructure code
Applicable tools & systems
TerraformPulumiAWS CloudFormation / CDKAzure Bicep / ARMGoogle Cloud infrastructure toolingAtlantis / Spacelift
TerraformApply saved plan sha256:… to prod-eu

Hold until the exact plan and workspace are approved.

PulumiDestroy stack payments/prod

Hold and route to the decommission path.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve workspace, backend, cloud identity, commit and environment from authoritative metadata.
  • Present creates, in-place updates, replacements, deletions and sensitive outputs separately to the approver.
  • Reject unsaved plans, auto-approved plans and any apply whose digest differs from the reviewed plan.
  • Require additional service-owner approval when the plan changes critical data, networking, identity or recovery controls.

Enforce at

Run production applies through a controlled CI identity that accepts only an approved plan artefact. Keep direct provider write credentials out of developer agents.

Exception / approval path

Emergency plan requires incident reference, exact digest, short expiry and an independent approver with authority over the affected services.

Test permitted, changed and denied paths
Should remain permitted

Generate a plan with a read/planning identity and apply the unchanged approved plan in the configured window.

Should be blocked or held

Use auto-approve, apply without a saved plan, change variables after approval or apply to another workspace.

Accountable ownerPlatform change owner
Critical severityCI-03
03

Block production cluster and service destruction

Block
Policy statement

Deny agent-initiated deletion of production clusters, namespaces, persistent storage and shared ingress, and deny scaling a critical service to zero outside an approved incident or deployment workflow.

Covered operations
  • Delete cluster, namespace, persistent volume or shared ingress
  • Delete all workloads by selector or manifest
  • Scale a protected production workload or node pool to zero
Applicable tools & systems
Kubernetes / kubectlHelmArgo CDFluxAWS EKSAzure AKSGoogle GKEOpenShift
kubectldelete namespace payments-prod

Block.

Kubernetes APIDeleteCollection deployments where app=checkout

Block when expansion includes all production replicas.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve cluster UID and namespace from kubeconfig plus flags; context names are not authoritative.
  • Expand --all, selectors, files, kustomize and Helm actions to the exact resource set and owner.
  • Block protected platform resources and unknown scope. Routine rollouts may use the approved deploy identity and availability constraints.

Enforce at

Use least-privilege Kubernetes RBAC, admission policy, protected GitOps paths and disruption/availability controls. Keep cluster-admin and namespace-delete permissions out of routine agents.

Exception / approval path

A separate incident or decommission workflow with the cluster owner; the agent does not receive standing cluster-admin credentials.

Test permitted, changed and denied paths
Should remain permitted

Read workload status or restart one permitted deployment through the approved rollout path.

Should be blocked or held

Delete a namespace, expand a selector to all workloads, delete persistent data or target an unresolved cluster context.

Accountable ownerKubernetes platform owner
Critical severityCI-04
04

Review changes that create public network exposure

Require approval
Policy statement

Hold network changes that make a previously private production service publicly reachable or materially broaden ingress to administrative, database or control-plane ports.

Covered operations
  • Add 0.0.0.0/0 or ::/0 ingress
  • Create public IP, public load balancer or internet gateway route
  • Disable private endpoint, WAF, mTLS or network policy protection
Applicable tools & systems
AWS VPC / EC2Azure Network Security GroupsGoogle Cloud VPCKubernetes NetworkPolicyCloudflareTerraform / Pulumi
AWS EC2Authorize 0.0.0.0/0 to tcp/5432 on a production security group

Hold for network security approval.

CloudflareDisable access policy on admin.example.com

Hold because it creates a public admin path.

Evaluation rules & enforcement

Evaluate these conditions

  • Evaluate the resulting reachable graph, not just the edited rule; include inherited groups, peerings, routes and load balancers.
  • Classify destination port and asset criticality, and identify compensating authentication and edge controls.
  • Aggregate staged changes that together create exposure. Approval binds to the final diff, source ranges, ports, duration and owner.

Enforce at

Use provider policy, policy-as-code and network admission controls to prevent unreviewed exposure. Re-evaluate reachability after apply and automatically expire temporary rules.

Exception / approval path

Approval covers exact asset, source, port, compensating controls and expiry. Material changes or extensions require new approval.

Test permitted, changed and denied paths
Should remain permitted

Narrow an existing ingress rule or add a time-bound internal source range to a non-critical service.

Should be blocked or held

Open a database/admin port globally, remove the private endpoint or split a public path across multiple changes.

Accountable ownerNetwork security owner
Critical severityCI-05
05

Block disabling security telemetry and preventive controls

Block
Policy statement

Deny agent changes that stop, delete or materially reduce required audit logging, threat detection, security scanning, WAF, endpoint protection or policy enforcement in production.

Covered operations
  • Stop or delete organisation audit trails and log sinks
  • Disable security services, policy engines, alert routes or tamper protection
  • Reduce required log retention or exclude protected event categories
Applicable tools & systems
AWS CloudTrail / GuardDuty / Security HubMicrosoft Defender for CloudGoogle Cloud Audit Logs / SCCCloudflare WAFKubernetes admission policyEDR platforms
AWS CloudTrailStopLogging on the organisation trail

Block.

Google CloudDelete the central audit log sink

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Maintain an authoritative list of required controls and their minimum configuration per account and environment.
  • Compare resulting state with the baseline and correlate sequences such as exclude-events then disable sink.
  • Do not grant the monitored agent identity authority to change the independent control or its audit destination.

Enforce at

Use organisation-level deny policy and a security-owned logging account/project. Generate a high-priority event on attempted tampering and retain the decision outside the affected scope.

Exception / approval path

No routine exception. Vendor-directed emergency maintenance uses a security-owned identity and dual control with compensating telemetry.

Test permitted, changed and denied paths
Should remain permitted

Add a new log sink or increase retention without weakening required coverage.

Should be blocked or held

Stop logging, delete the central trail, add an exclusion for privileged changes or disable a required detector.

Accountable ownerSecurity operations
Critical severityCI-06
06

Block destruction or uncontrolled export of production encryption keys

Block
Policy statement

Deny scheduling deletion, disabling, exporting or weakening access policy for production encryption and signing keys used by critical services or protected data.

Covered operations
  • Schedule/delete/disable key or vault
  • Export key material or make it broadly accessible
  • Change rotation, key policy or recovery protection below baseline
Applicable tools & systems
AWS KMS / CloudHSMAzure Key Vault / Managed HSMGoogle Cloud KMSHashiCorp VaultThales / HSM platforms
AWS KMSScheduleKeyDeletion on the production payments key

Block.

Azure Key VaultPurge a soft-deleted production vault

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve key ARN/ID, aliases, owning vault/project, downstream encrypted resources and signing consumers.
  • Treat alias changes and key replacement as consequential when they redirect a protected workload.
  • Block self-grants and any policy change that gives the agent or a public principal decrypt, sign, export or administration rights.

Enforce at

Use key policies, separation of duties, purge protection and independent key-administrator identities. The workload and agent identities should consume keys without administering them.

Exception / approval path

Key retirement follows a cryptographic lifecycle process with dependency proof, recovery/escrow checks and two authorised custodians.

Test permitted, changed and denied paths
Should remain permitted

Read key metadata or perform an authorised encrypt/decrypt operation through the workload role.

Should be blocked or held

Schedule deletion, purge the vault, export key material or add the agent as key administrator.

Accountable ownerCryptographic key owner
03 / 09 · Control domain

Identity & privileged access

Let agents assist with access administration while ensuring they cannot expand their own authority, create standing privileged access or weaken authentication controls.

6 policies26 applicable systemsOwners: Identity platform owner + security operationsDownload pack .md
Control scope and what to configure first
Protected assetsUsers, groups, roles, policies, service principals, workload identities and authentication controls
Consequential actionsPrivilege grants, self-modification, credential creation, MFA/SSO changes and bulk lifecycle operations
Applicable systemsMicrosoft 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.
Authoritative boundary
Keep protected identity administration outside the agent credential. Use PIM/JIT, policy conditions, approval workflows and immutable audit events at the identity provider.
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
Policy set

Policies in this domain.

6 of 6 policies
Critical severityIA-01
01

Block agent self-escalation and guardrail modification

Block
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
Applicable tools & systems
AWS IAMMicrosoft Entra IDGoogle Cloud IAMOktaGoogle WorkspaceGitHub EnterpriseKubernetes RBAC
AWS IAMAttach AdministratorAccess to the current agent role

Block.

Microsoft Entra IDAdd the agent service principal as an owner of a privileged app

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • 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.

Enforce at

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 path

None. Any access expansion must be executed by a different, authorised identity after independent review.

Test permitted, changed and denied paths
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.

Critical severityIA-02
02

Keep tier-zero and organisation-wide administration out of agent scope

Block
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
Applicable tools & systems
Microsoft Entra IDOktaGoogle WorkspaceAWS Organizations / IAMGoogle Cloud IAMAzure RBACGitHub Enterprise
Microsoft Entra IDAssign Global Administrator to agent-app

Block.

Google CloudGrant roles/resourcemanager.organizationAdmin to an automation principal

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • 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.

Enforce at

Exclude tier-zero actions from routine agent credentials and require a hardened privileged-access workstation and JIT workflow for authorised humans.

Exception / approval path

No agent exception. Break-glass use is human-only, separately monitored and reviewed immediately after use.

Test permitted, changed and denied paths
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.

High severityIA-03
03

Require scoped, time-bound approval for privileged access

Require approval
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
Applicable tools & systems
Microsoft Entra PIMAWS IAM Identity CenterGoogle Cloud IAMOktaTeleportCyberArkHashiCorp Boundary
Azure PIMActivate Contributor on subscription prod for 60 minutes

Hold for configured approver and reason.

AWS IAM Identity CenterAssign database-admin permission set to one production account

Hold and expire automatically.

Evaluation rules & enforcement

Evaluate these conditions

  • 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.

Enforce at

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 path

Emergency access requires the incident identifier and an approved break-glass path; it expires quickly and triggers retrospective review.

Test permitted, changed and denied paths
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.

Critical severityIA-04
04

Block weakening of authentication and session controls

Block
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
Applicable tools & systems
Microsoft Entra IDOktaGoogle WorkspaceDuoPing IdentityAuth0AWS IAM Identity Center
OktaExclude Engineering-All from the phishing-resistant MFA rule

Block.

Microsoft Entra IDSet conditional-access policy state to disabled

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • 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.

Enforce at

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 path

A security-led outage procedure may use narrowly scoped, expiring exclusions with compensating monitoring; agents cannot approve or execute it alone.

Test permitted, changed and denied paths
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.

Accountable ownerAuthentication platform owner
High severityIA-05
05

Review bulk user suspension, deletion and access revocation

Require two-person approval
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
Applicable tools & systems
Microsoft Entra IDOktaGoogle WorkspaceOneLoginHRIS provisioningSCIM integrationsGitHub Enterprise
Google WorkspaceSuspend all users matching department=Sales

Hold and expand the exact population.

OktaDeactivate 250 imported users

Hold for two-person approval.

Evaluation rules & enforcement

Evaluate these conditions

  • 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.

Enforce at

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 path

Incident containment can use a security-approved population and short-lived session revocation; permanent deletion waits for normal review.

Test permitted, changed and denied paths
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.

Accountable ownerIdentity operations + business owner
High severityIA-06
06

Block unmanaged long-lived credentials

Block
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
Applicable tools & systems
AWS IAM / STSMicrosoft Entra workload identityGoogle Cloud IAMGitHubGitLabKubernetesHashiCorp Vault
Google Cloud IAMCreate a downloadable service-account JSON key

Block for routine agent use.

GitHubCreate a classic PAT with repo and admin:org scopes

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • 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.

Enforce at

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 path

A documented legacy-system exception requires minimum scope, short expiry, managed-vault delivery and an accountable rotation owner.

Test permitted, changed and denied paths
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.

Accountable ownerWorkload identity owner
04 / 09 · Control domain

Sensitive data movement

Permit scoped retrieval and analysis while preventing cross-tenant access, uncontrolled exports, public sharing and production-data copies into ungoverned environments.

6 policies37 applicable systemsOwners: Data protection owner + system data ownerDownload pack .md
Control scope and what to configure first
Protected assetsSecrets, credentials, customer records, employee records, payment data and regulated datasets
Consequential actionsRetrieval, export, copy, upload, paste, sharing, cross-tenant access and non-production replication
Applicable systemsData warehouses, object stores, CRM, document suites, messaging, browsers and AI assistants
Context to resolve
Resolve classification, record count, fields, tenant, residency, destination tenant/domain, recipient membership and device/workspace trust.
Authoritative boundary
Combine source-system entitlements, field/row security, DLP and destination controls. Browser paste, uploads and screenshots require endpoint/browser coverage in addition to API controls.
Configure first
  • Data classifications, tenant ownership, residency rules and approved processing destinations
  • Export thresholds, permitted recipient domains, managed devices and expiring share settings
  • Tokenisation, masking and synthetic-data standards for non-production environments
Policy set

Policies in this domain.

6 of 6 policies
Critical severitySD-01
01

Block secrets from leaving approved secret-handling paths

Block
Policy statement

Deny retrieval or transfer of passwords, private keys, access tokens, recovery codes and live credentials into prompts, tickets, chat, email, logs or unapproved files.

Covered operations
  • Read and return secret value
  • Upload, paste, message or email detected secret material
  • Write secret to source code, build output, ticket or shared document
Applicable tools & systems
AWS Secrets ManagerAzure Key VaultGoogle Secret ManagerHashiCorp VaultGitHub / GitLabSlack / TeamsJira / ServiceNow
AWS Secrets ManagerGetSecretValue then paste result into a support ticket

Block before retrieval or transfer.

SlackPost a private key to an incident channel

Block even if the channel is internal.

Evaluation rules & enforcement

Evaluate these conditions

  • Combine source classification with secret-pattern and entropy detection; never log the full matched value.
  • Resolve destination tenant, workspace, channel, recipients and retention before transfer.
  • Allow workload-side secret references or handles, not disclosure of secret material to the conversational model.

Enforce at

Expose reference-based secret operations to agents and keep value retrieval in the workload. Add DLP/secret scanning at browser, messaging, repository and ticket boundaries.

Exception / approval path

No chat-based exception. Human recovery uses the secret system’s audited reveal process on a managed device.

Test permitted, changed and denied paths
Should remain permitted

Reference a secret by identifier in deployment configuration without revealing its value.

Should be blocked or held

Retrieve and print a secret, encode it to evade detection or place it in a repository, prompt, ticket or message.

Accountable ownerSecrets platform owner
Critical severitySD-02
02

Block cross-tenant customer data access

Block
Policy statement

Deny reads and writes when the requested customer, account, case or object does not belong to the tenant and assignment established by the active work context.

Covered operations
  • Retrieve record by guessed ID outside assigned tenant
  • Join, search or aggregate across tenants
  • Update or attach one tenant’s data to another tenant’s case
Applicable tools & systems
SalesforceHubSpotZendeskIntercomServiceNowDatabases / warehousesObject storage
SalesforceRead account 001… belonging to another region/tenant

Block.

ZendeskAttach customer A’s diagnostic file to customer B’s ticket

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Derive tenant and assignment from signed session context and source-system entitlements, never from model-supplied fields.
  • Enforce row/object-level ownership on every lookup, relationship expansion, export and write.
  • Fail closed on missing tenant mapping and prevent sequential-ID or broad-search enumeration.

Enforce at

Enforce tenant isolation in the API and data layer with row/object security and scoped credentials. Agent-side intent checks add context but are not the isolation boundary.

Exception / approval path

Cross-tenant investigations require an authorised support/security role, named tenants, a case reference and time-bound access.

Test permitted, changed and denied paths
Should remain permitted

Retrieve the minimum permitted fields for the customer linked to the assigned case.

Should be blocked or held

Change the record ID, use global search or follow a relationship to access another tenant’s data.

Accountable ownerCustomer data owner
High severitySD-03
03

Review bulk exports of regulated or confidential data

Require approval
Policy statement

Hold exports of confidential, personal, health, payment or employee data when fields, row count, file size or query scope exceed the data owner’s approved threshold.

Covered operations
  • CSV/JSON export or bulk API extraction
  • Warehouse unload to object storage
  • CRM, HRIS or support bulk export
  • Repeated smaller exports that cumulatively cross the threshold
Applicable tools & systems
SnowflakeBigQueryDatabricksRedshiftSalesforceWorkday / HRISZendeskS3 / GCS / Azure Blob
SnowflakeCOPY 2.4M customer rows with email and DOB to an external stage

Hold for data-owner approval.

SalesforceBulk export all contacts to a local CSV

Hold and verify destination/device.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve classifications at field level, exact row estimate, tenant set, destination, recipient and retention.
  • Aggregate related exports and include query, filters and selected fields in the approved digest.
  • Require a managed encrypted destination and minimum necessary fields; block unknown or personal destinations.

Enforce at

Use field/row policy, export entitlements, DLP classification and a broker that writes only to approved destinations. Preserve query and destination evidence without duplicating sensitive content.

Exception / approval path

Approval covers purpose, exact fields/query, population, destination, recipients, retention and expiry. New purpose or destination needs a new decision.

Test permitted, changed and denied paths
Should remain permitted

Export an approved aggregate without direct identifiers to a governed analytics workspace.

Should be blocked or held

Add sensitive fields after approval, switch to a personal destination or split a large export into small batches.

High severitySD-04
04

Review public links and external sharing of sensitive content

Require approval
Policy statement

Hold external sharing of confidential or restricted files and deny anonymous/public links. Approval must cover the exact content version and verified recipients.

Covered operations
  • Create public/anonymous link
  • Share outside approved domains or guest groups
  • Change link permissions, download settings or expiry
  • Post sensitive attachment to an external channel
Applicable tools & systems
Google DriveMicrosoft 365 / SharePointBoxDropboxSlack ConnectMicrosoft TeamsDocuSign
Google DriveSet board-plan.pdf to anyone-with-link

Block.

Microsoft SharePointShare restricted contract with counsel@example.com for 7 days

Hold for matter-owner approval.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve file classification, matter/customer ownership, content version, recipient identities, guest membership and link settings at share time.
  • Deny anonymous access for sensitive content and enforce the shortest practical expiry and least permission.
  • Invalidate approval when the content, recipients, permission or destination changes.

Enforce at

Use source-system classification, domain restrictions, guest policy and DLP at the sharing API. Re-check recipients and classification immediately before creating the share.

Exception / approval path

One approved content digest, named recipient set, permission and expiry; anonymous links remain prohibited for sensitive classes.

Test permitted, changed and denied paths
Should remain permitted

Share an internal-classified document with a named employee who already has approved workspace access.

Should be blocked or held

Create an anonymous link, change recipient after approval or share a revised sensitive document under an old approval.

Accountable ownerDocument or matter owner
Critical severitySD-05
05

Block raw production data in lower-trust environments

Block
Policy statement

Deny copying, restoring or replicating raw production datasets into development, test, personal or third-party environments unless an approved transformation removes protected data first.

Covered operations
  • Restore production snapshot into dev/test account
  • Clone warehouse/database across trust boundary
  • Copy production object-store prefix to lower environment
  • Disable masking or tokenisation on replicated data
Applicable tools & systems
AWS RDS / S3Google Cloud SQL / BigQuery / GCSAzure SQL / BlobSnowflakeDatabricksMongoDB AtlasTest-data platforms
AWS RDSRestore prod snapshot into shared-dev account

Block until an approved masked derivative is produced.

SnowflakeClone prod.customer to developer personal database

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Compare source and destination trust, tenant, region and access population; do not rely on resource names.
  • Require approved masking/tokenisation job and verify the resulting classification before granting access.
  • Block copies containing secrets, live payment data or direct identifiers when no approved transformation exists.

Enforce at

Use cross-account policy, snapshot permissions and governed data pipelines. Create masked or synthetic datasets through a controlled identity and classify the output before release.

Exception / approval path

A time-bound, isolated investigation environment requires privacy/security approval, named users, monitoring and verified destruction.

Test permitted, changed and denied paths
Should remain permitted

Create a synthetic or verified masked dataset in the approved test account.

Should be blocked or held

Share the raw snapshot, restore it to a lower-trust account or disable masking after access is granted.

Accountable ownerData protection owner
High severitySD-06
06

Review cross-region and cross-tenant regulated-data transfers

Require approval
Policy statement

Hold transfers of regulated data to a different region, country, cloud account or SaaS tenant unless the destination is pre-approved for that classification and purpose.

Covered operations
  • Cross-region replication or export
  • Copy to another cloud account/project/subscription
  • Upload to external SaaS or AI workspace
  • Change residency, replication or backup location
Applicable tools & systems
AWS / Azure / Google Cloud storageSnowflakeDatabricksGoogle WorkspaceMicrosoft 365Browser AIMCP and SaaS connectors
Google Cloud StorageCopy AU customer export to a US multi-region bucket

Hold for residency review.

Browser AIUpload a payroll workbook to a personal AI workspace

Block as an unapproved tenant.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve source classification and residency plus destination legal entity, tenant, region, processor and retention.
  • Check an owned allowlist tied to data class and purpose; a vendor name alone is insufficient.
  • Bind approval to dataset/query, destination, purpose and retention and aggregate related transfers.

Enforce at

Use organisation policy, storage controls, tenant restrictions, CASB/DLP and approved connector identities. Monitor the downstream result and record destination identifiers.

Exception / approval path

Requires documented purpose, legal/privacy basis where applicable, exact destination, retention and expiry; emergency does not waive destination security.

Test permitted, changed and denied paths
Should remain permitted

Send an approved minimal dataset to a governed in-region processor for the recorded purpose.

Should be blocked or held

Change region or tenant after approval, use a personal workspace or omit destination context.

Accountable ownerPrivacy and data residency owner
05 / 09 · Control domain

Software delivery & supply chain

Allow code generation and delivery automation while preserving review, provenance, protected branches, release authority and build-system integrity.

6 policies37 applicable systemsOwners: Developer platform owner + application securityDownload pack .md
Control scope and what to configure first
Protected assetsSource repositories, CI workflows, build identities, packages, images and release environments
Consequential actionsProtection bypass, workflow privilege change, artifact publication, secret exposure and production deploy
Applicable systemsGitHub, GitLab, Bitbucket, CI platforms, package registries, container registries and deployment systems
Context to resolve
Resolve repository, branch, commit, diff, workflow permissions, dependency provenance, artifact digest, environment and release approver.
Authoritative boundary
Repository rules, environment protection, isolated builders, registry permissions and deploy identities are authoritative. Agent policy adds intent and context before those boundaries.
Configure first
  • Protected repositories, branches, release environments, registries and production deploy targets
  • Required checks, reviewers, trusted builders, signing identities and provenance requirements
  • High-risk CI permissions, third-party action policy and emergency rollback workflow
Policy set

Policies in this domain.

6 of 6 policies
Critical severitySW-01
01

Block bypass or removal of protected-branch controls

Block
Policy statement

Deny agent actions that remove or bypass required reviews, status checks, signed commits, merge queue, force-push protection or restricted deletion on protected repositories and branches.

Covered operations
  • Delete or weaken branch/ruleset protection
  • Force push or direct push to protected branch
  • Dismiss reviews or bypass required checks
  • Delete protected release branch or tag
Applicable tools & systems
GitHubGitLabBitbucketAzure DevOps ReposGerrit
GitHubAdd the agent app to the main ruleset bypass list

Block.

GitLabForce-push generated changes directly to the protected release branch

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve repository ID, branch/tag, applicable inherited ruleset and bypass actor from the destination API.
  • Compare resulting protection strength and detect equivalent bypass via custom roles, apps or temporary rule disablement.
  • Do not allow the code-writing agent to add itself or its app to a bypass list.

Enforce at

Use organisation-owned repository rulesets and app permissions that cannot administer protection. Require changes through pull/merge requests and destination-native checks.

Exception / approval path

A human incident owner may use a destination-native, logged bypass when configured; the coding agent cannot hold reusable bypass authority.

Test permitted, changed and denied paths
Should remain permitted

Create a feature branch and open a pull request that is subject to all required checks.

Should be blocked or held

Disable the ruleset, self-add to bypass, dismiss a required review or force-push to the protected branch.

Accountable ownerRepository owner
Critical severitySW-02
02

Review CI changes that expand code-execution privilege

Require approval
Policy statement

Hold workflow changes that add privileged runners, write tokens, untrusted third-party actions, secret access, production credentials or execution of fork-controlled code.

Covered operations
  • Edit CI workflow or runner configuration
  • Increase token permissions or secret availability
  • Add/change third-party action, image or remote script
  • Change environment protection or deploy credentials
Applicable tools & systems
GitHub ActionsGitLab CIJenkinsCircleCIBuildkiteAzure PipelinesAWS CodeBuild
GitHub ActionsChange permissions: contents: read to contents: write and add pull_request_target

Hold for security review.

GitLab CIRun a curl | sh step on a privileged production runner

Hold.

Evaluation rules & enforcement

Evaluate these conditions

  • Evaluate the workflow diff and effective permissions, events, runner trust, secret flow and pinned dependency provenance.
  • Require security review for pull-request-triggered workflows that access secrets or write permissions.
  • Bind approval to commit and workflow digest; later edits invalidate approval.

Enforce at

Protect workflow paths with CODEOWNERS/rulesets, use isolated least-privilege runners and default read-only tokens. Evaluate third-party actions and images by immutable digest.

Exception / approval path

Approval covers exact commit, workflow permissions, runner and dependencies. Emergency changes use the protected repository process and remain reviewable.

Test permitted, changed and denied paths
Should remain permitted

Change a test command without altering permissions, events, runner class, secrets or external code sources.

Should be blocked or held

Add write permission after approval, reference a floating untrusted action or expose secrets to fork-controlled code.

Accountable ownerCI platform owner + application security
Critical severitySW-03
03

Block publication of untrusted or untraceable artifacts

Block
Policy statement

Deny publication or promotion of packages, containers and release artifacts that were not built by an approved builder from a reviewed commit or that fail required signing, provenance, malware and vulnerability policy.

Covered operations
  • Publish package or container
  • Promote artifact to production registry/channel
  • Replace mutable release tag
  • Disable signing, provenance or security scan requirement
Applicable tools & systems
GitHub PackagesGitLab RegistryAmazon ECRGoogle Artifact RegistryAzure Container RegistrynpmPyPIJFrog Artifactory
Container registryPush local image to payments:latest in the production registry

Block.

npm / PyPIPublish a package version without the protected release workflow

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve artifact digest, source commit, builder identity, provenance, dependency state and scan results.
  • Decide on immutable digest, not tag or filename. Reject local developer builds for protected publication channels.
  • Block mutable overwrite of released versions and any attempt to bypass required attestations.

Enforce at

Allow protected publication only from the trusted build identity, verify signed provenance/attestations and make released versions immutable where supported.

Exception / approval path

A quarantined emergency artifact still requires known source, digest, independent approval and retrospective completion of evidence before broader promotion.

Test permitted, changed and denied paths
Should remain permitted

Publish a signed artifact from the approved builder with matching commit and passing policy.

Should be blocked or held

Publish from a laptop, reuse a tag for a different digest or omit required provenance/scan evidence.

Accountable ownerArtifact registry owner
Critical severitySW-04
04

Approve the exact artifact deployed to production

Require approval
Policy statement

Hold production deploys and rollbacks unless approval is bound to the immutable artifact digest, target environment, release plan and valid change window.

Covered operations
  • Deploy/promote release to production
  • Rollback to an earlier artifact or database state
  • Change target environment, region, traffic percentage or release parameters
Applicable tools & systems
GitHub EnvironmentsGitLab DeploymentsArgo CDFluxSpinnakerHarnessKubernetesCloud deployment services
Argo CDSync payments-prod to image digest sha256:…

Hold until that digest and target are approved.

GitHub EnvironmentsDeploy a different artifact after environment approval

Hold again.

Evaluation rules & enforcement

Evaluate these conditions

  • Verify artifact provenance and map digest to reviewed source commit and passing checks.
  • Resolve target environment/regions and service owner. Treat rollback as a new consequential action with known compatibility.
  • Invalidate approval on digest, configuration, migration, target or rollout-strategy changes.

Enforce at

Use protected deployment environments and a deploy identity that accepts immutable digests only. Record downstream deployment result and preserve separation between requester and approver.

Exception / approval path

Incident rollback requires incident commander approval, exact rollback digest and compatibility evidence; approval expires with the incident window.

Test permitted, changed and denied paths
Should remain permitted

Deploy the exact approved digest to the approved environment during the window.

Should be blocked or held

Change tag/digest, add a region, alter migration inputs or reuse approval for another service.

Critical severitySW-05
05

Block credential and sensitive-data leakage through delivery systems

Block
Policy statement

Deny commits, workflow changes, build output and artifacts that expose live secrets, private keys, tokens or restricted production data.

Covered operations
  • Commit or push detected secret
  • Echo secret to CI log or test report
  • Upload secret-bearing artifact, cache or debug bundle
  • Expose production data in fixture or preview environment
Applicable tools & systems
GitHubGitLabBitbucketCI platformsArtifact registriesSecret managersPreview deployment platforms
GitPush .env.production containing a live API key

Block and rotate the credential.

CIUpload a debug artifact containing a production database dump

Block.

Evaluation rules & enforcement

Evaluate these conditions

  • Inspect staged diff, generated files, workflow log commands and artifact manifests without retaining full secret values.
  • Treat encoding, archives and generated outputs as possible disclosure paths.
  • On a confirmed live secret, block publication and initiate revocation/rotation; deleting the commit alone is insufficient.

Enforce at

Combine pre-receive/push protection, CI secret scanning, log masking and artifact DLP. Keep production data out of build identities and revoke exposed credentials through the system of record.

Exception / approval path

No disclosure exception. False positives can be reviewed using a fingerprint; live secret values remain prohibited.

Test permitted, changed and denied paths
Should remain permitted

Commit a documented placeholder or secret reference that cannot authenticate.

Should be blocked or held

Encode a live key, expose it in logs or upload a dump through a build artifact or preview deployment.

Accountable ownerApplication security + secrets owner
High severitySW-06
06

Require human review of agent-authored changes to security-sensitive paths

Require approval
Policy statement

Hold merge of any change authored or co-authored by a coding agent that touches authentication, authorisation, cryptography, secrets handling, CI workflows, infrastructure code or dependency manifests until a named human reviewer who did not prompt the agent has approved the exact diff. An agent may not approve, self-merge or dismiss reviews on its own change.

Covered operations
  • Open, update or merge a pull request whose commits carry an agent author or co-author
  • Approve or dismiss a review on a pull request the same agent identity created
  • Add, remove or upgrade a dependency in a manifest or lockfile through an agent
  • Change CODEOWNERS, required reviewers or the review policy for a protected path
Applicable tools & systems
GitHubGitLabBitbucketGitHub CopilotClaude CodeCursorCodexDependabot / Renovate
GitHubCopilot agent opens a pull request that rewrites the session-token validator and requests review from its prompter

Hold for a CODEOWNERS reviewer who did not prompt the change.

GitLabAgent-authored merge request adds a new transitive dependency with no provenance attestation

Hold until the package is reviewed and pinned.

Claude CodeAgent approves and merges its own change to the deploy workflow

Block the self-approval; route to a human reviewer.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the agent identity from commit trailers, the token used and the assistant session; treat a change with no attributable human author as agent-authored.
  • Match the diff against the protected path set (auth, crypto, secrets, CI, infrastructure, manifests) and hold when any hunk lands in it.
  • Require the approving reviewer to differ from the person who prompted the agent and from the agent identity; invalidate approval when the diff changes after review.
  • Hold dependency additions whose package has no verified provenance or was first published recently, and never let the agent resolve a missing package by publishing one.

Enforce at

Use rulesets with required reviewers and CODEOWNERS on protected paths, block self-approval and require provenance checks in CI. The control plane records the agent, session and prompter behind each change and holds merges before the repository rule applies.

Exception / approval path

Emergency fixes still require an independent human approval; the reviewer may be paged, but the agent and the prompter cannot approve.

Test permitted, changed and denied paths
Should remain permitted

Merge an agent-authored documentation or test-only change with one human approval, or a protected-path change approved by an independent CODEOWNERS reviewer.

Should be blocked or held

Merge an agent-authored change to the auth module approved only by its prompter, or let the agent dismiss a review and merge its own workflow edit.

06 / 09 · Control domain

Shadow AI tooling

Let people use AI tools that are sanctioned and reached through the approved tenant, gateway or proxy, while stopping company data from leaving through unmanaged AI accounts and stopping unreviewed extensions, connectors, models and skills from entering the environment.

7 policies42 applicable systemsOwners: AI platform owner + data protection owner + endpoint securityDownload pack .md

State of Shadow AI report. The research behind this pack: 78% of AI users bring their own tools, 63% of organisations have no AI governance policy, and shadow AI adds $670K to the average breach. Read the research

Control scope and what to configure first
Protected assetsSource code, customer and employee records, credentials, confidential documents, agent configuration and the model and skill artifacts agents run
Consequential actionsPaste and upload to unmanaged accounts, extension install, assistant sign-in, connector registration, model and skill load, vendor AI enablement and app consent
Applicable systemsConsumer and enterprise AI assistants, browsers, IDEs and coding agents, MCP servers, public model and skill hubs, SaaS AI features and identity providers
Context to resolve
Resolve the authenticated tenant, publisher and version, requested permissions and scopes, data classification at egress, route (gateway, proxy, direct) and the inventory entry an action maps to.
Authoritative boundary
Tenant restrictions, identity-provider consent policy, browser and editor management policies, gateway registry and artifact-proxy egress rules are the hard boundary. Agent, CLI and MCP interception adds the intent-aware decision and the record.
Configure first
  • Sanctioned AI tool inventory: providers, enterprise tenants, approved extensions, registered MCP servers and the internal model and skill catalogue
  • Discovery sources: browser management, cloud app discovery, identity-provider consent logs, network egress and endpoint DLP
  • AI tool intake process with named reviewers, pilot rules, expiry dates and the gateway and artifact-proxy routes every sanctioned tool must use
Policy set

Policies in this domain.

7 of 7 policies
Critical severitySA-01
01

Block work data in personal and unmanaged AI accounts

Block
Policy statement

Deny pasting, uploading or synchronising company source code, customer records, credentials or confidential documents into an AI assistant account that is outside the organisation’s tenant, contract and data-processing agreement. A consumer subscription used for work is unmanaged regardless of who pays for it.

Covered operations
  • Paste or type confidential content into a consumer chatbot session
  • Upload files, screenshots or repositories to a personal AI account
  • Connect a personal AI account to company mail, drive, calendar or chat
  • Route API traffic to an AI provider using a personal or unmanaged API key
Applicable tools & systems
ChatGPTClaudeGeminiMicrosoft CopilotPerplexityBrowserDesktop AI appsProvider APIs
BrowserPaste a customer export into a consumer chatbot logged in with a personal email

Block and point the user to the sanctioned tenant.

Desktop AI appConnect a personal AI account to the company Google Drive

Block the OAuth grant at the identity provider.

TerminalCall a model API with a key that is not from the company organisation while a repository is in context

Block when the request body contains protected content.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the destination tenant from the authenticated account, not the vendor domain: the same provider can be sanctioned under the enterprise tenant and unmanaged under a personal login.
  • Classify the content at the point of egress (clipboard, upload, connector sync, outbound API) using the data classification of its source, not the user’s description of it.
  • Block when classification is confidential or higher and the destination account is not in the sanctioned tenant list; hold when the classification cannot be resolved.
  • Treat an API key that is not issued from the organisation’s provider organisation as a personal key and block outbound calls that carry protected data.

Enforce at

Combine tenant-restriction headers and identity-provider consent controls with endpoint and browser DLP for paste and upload. Intercept agent, CLI and MCP egress for content-aware decisions; the sanctioned tenant and the DLP boundary are the final controls.

Exception / approval path

No self-service exception. A team that needs a provider not yet sanctioned requests it through the AI tool intake process, which onboards an enterprise tenant rather than approving personal use.

Test permitted, changed and denied paths
Should remain permitted

Paste the same content into the sanctioned enterprise tenant of the same provider, or use a personal account for content classified as public.

Should be blocked or held

Upload a confidential file to a personal account, grant a personal AI app access to company drive, or split a protected document across several pastes.

High severitySA-02
02

Review browser extensions with AI features that read page content

Require approval
Policy statement

Hold installation or permission expansion of any browser extension that sends page content, form input or clipboard data to a model or third-party service until the publisher, permissions and data flow have been reviewed and the extension is on the managed allowlist.

Covered operations
  • Install an extension requesting host access to all sites or to company SaaS domains
  • Grant an existing extension new permissions after an update
  • Enable an AI writing, summarising or recording feature inside a sanctioned extension
  • Side-load an unpacked extension outside the managed store
Applicable tools & systems
ChromeMicrosoft EdgeFirefoxSafariBrowser management (Chrome Enterprise, Intune, Jamf)Endpoint DLP
ChromeInstall a meeting-summary extension requesting access to all sites

Hold for security review and allowlisting.

EdgeExtension update adds clipboard read and a new remote endpoint

Hold the update as a new permission set.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the extension by store ID and version, its publisher, its requested host and API permissions, and the endpoints it sends data to.
  • Hold when host permissions include company SaaS, mail or source-control domains and the extension is not on the allowlist for that permission set.
  • Treat a permission increase on update as a new install; the previous approval does not carry over.
  • Block side-loaded or developer-mode extensions on managed devices outside an approved engineering exception.

Enforce at

Use browser management policies (install allowlist and blocklist, blocked permissions, forced installs) delivered through device management. The AI gateway records which sanctioned extensions may reach which model endpoints; the browser policy is the hard boundary.

Exception / approval path

A time-boxed pilot on a named device group with the extension’s data flow documented; the allowlist entry expires with the pilot unless renewed.

Test permitted, changed and denied paths
Should remain permitted

Install an allowlisted extension whose permission set matches the approved version.

Should be blocked or held

Install an unlisted AI extension with broad host access, accept a permission-expanding update, or side-load the same extension from a folder.

High severitySA-03
03

Require approval for AI coding assistants and IDE extensions from public registries

Require approval
Policy statement

Hold installation of any coding assistant, agent or IDE extension pulled from a public registry until its publisher is verified, its version is pinned and its permissions (workspace access, shell execution, network egress) are reviewed. Sanctioned assistants run under the organisation’s tenant with content exclusions configured.

Covered operations
  • Install an IDE extension or agent plugin from a public registry
  • Enable auto-update for an extension with shell or network access
  • Sign into a coding assistant with a personal account inside a company workspace
  • Add an agent instruction file or rules file that grants tools or turns off approvals
Applicable tools & systems
VS CodeCursorJetBrains IDEsGitHub CopilotClaude CodeCodexOpen VSX / VS Code MarketplaceJetBrains Marketplace
VS CodeInstall a coding assistant from a look-alike publisher on Open VSX

Hold; publisher is not verified and the ID is not on the allowlist.

CursorSign in with a personal account in the company monorepo

Hold until the session uses the enterprise tenant.

Claude CodeCommit a settings file that allows every shell command without prompting

Hold for developer platform review.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the registry, publisher identity, extension ID, version and declared capabilities; an unverified publisher or a name that mimics a sanctioned extension is held.
  • Hold when the extension can execute shell commands, read the whole workspace or reach network endpoints and is not on the pinned allowlist.
  • Require the assistant to be signed in under the organisation’s tenant; hold sessions authenticated with a personal account while a company repository is open.
  • Treat rules, settings or instruction files that disable permission prompts or expand tool access as a policy change requiring the same review as the extension itself.

Enforce at

Use editor enterprise policies (allowed extensions, allowed publishers, pinned versions) delivered by device management, and configure assistant content exclusions for sensitive paths. The control plane records the assistant, version and tenant behind each action; the editor policy is the hard boundary.

Exception / approval path

An engineering exception names the extension ID, version and device group, and expires within 30 days unless the extension is promoted to the allowlist.

Test permitted, changed and denied paths
Should remain permitted

Install a pinned, allowlisted assistant under the enterprise tenant and use it with content exclusions in place.

Should be blocked or held

Install an unlisted extension with shell access, sign in with a personal account in a company repository, or disable permission prompts through a committed settings file.

Critical severitySA-04
04

Block unsanctioned MCP servers and agent connectors

Block
Policy statement

Deny agents from connecting to an MCP server, plugin or connector that is not registered with the organisation’s gateway, and deny edits to agent configuration that add a direct server URL, command or credential bypassing that gateway. Sanctioned servers are reached through one endpoint with per-user credentials.

Covered operations
  • Add an MCP server entry to a user, project or IDE configuration file
  • Launch a local MCP server from a package fetched at runtime
  • Connect an agent to a remote MCP endpoint with a shared or embedded credential
  • Install a connector or plugin that exposes company systems as agent tools
Applicable tools & systems
Claude CodeCursorVS CodeCodexWindsurfMCP serversCustom agentsTracelet MCP gateway
Claude CodeAdd a third-party database MCP server with an embedded connection string to the project config

Block; the database is fronted by the gateway.

CursorAgent edits its own MCP configuration to add a server it found in a README

Block the self-modification and record the attempt.

TerminalRun an MCP server from an unpinned package pulled at startup

Block until the package is registered and pinned.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the server by its endpoint or launch command, its package and version, the tools it exposes and the credential it uses; an entry that cannot be matched to the gateway registry is unsanctioned.
  • Block configuration changes that introduce a direct server URL or command for a system the gateway already fronts, including changes made by the agent itself.
  • Block connectors whose tool descriptions or responses contain instructions to the model (tool poisoning) and quarantine the server pending review.
  • Deny shared, long-lived or embedded credentials in connector configuration; the gateway fetches a per-user credential at call time.

Enforce at

Publish sanctioned servers through the MCP gateway with policy checks, roles and per-user credentials from the secret store. Protect agent configuration files with endpoint policy and repository rules; the gateway registry and network egress controls are the hard boundary.

Exception / approval path

Registering a new server through the gateway intake: publisher, version, exposed tools and credential model reviewed, then published to named roles. No exception for direct connections.

Test permitted, changed and denied paths
Should remain permitted

Connect to a registered server through the gateway endpoint and call a tool the caller’s role permits.

Should be blocked or held

Add a direct server entry for a gateway-fronted system, launch an unregistered local server, or let the agent modify its own connector configuration.

Critical severitySA-05
05

Block untrusted models, datasets and agent skills from public hubs

Block
Policy statement

Deny loading or executing a model, dataset, prompt package or agent skill from a public hub unless it comes from an approved publisher, uses a non-executable format or has passed the organisation’s scan, and is pinned by digest. A skill is executable content and is reviewed as code.

Covered operations
  • Download and load a model file in a serialisation format that can execute code
  • Install an agent skill, prompt pack or tool bundle from a marketplace
  • Pull a dataset or model into a build, notebook or agent runtime at run time
  • Run a model or skill whose digest differs from the reviewed version
Applicable tools & systems
Hugging Face HubPyTorch / TensorFlowOllamaAgent skill marketplacesClaude CodeCursorInternal artifact proxy (Artifactory, Nexus)CI platforms
Python / Hugging Face HubLoad a pickle model from an unverified repository at notebook start

Block; require a scanned, digest-pinned safetensors artifact from the internal proxy.

Agent marketplaceInstall a skill that grants shell and network tools from an unknown publisher

Block and route to skill review.

CIPull a model by floating tag into the inference image build

Block until the revision is pinned by digest.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the hub, publisher, repository, revision and file digest; a floating tag or unpinned revision is unresolved and is blocked for anything that executes.
  • Block pickle-based and other executable model formats unless the file is from an approved publisher and passed a malware and pickle scan; prefer safetensors or equivalent non-executable formats.
  • Treat agent skills and prompt packs as third-party code: review for embedded instructions, tool grants and outbound calls before allowing an agent to run them.
  • Block runtime downloads that bypass the internal artifact proxy so provenance is recorded for every artifact an agent runs.

Enforce at

Route model and skill downloads through an internal artifact proxy with scanning and digest pinning, and deny direct egress to public hubs from build and agent runtimes. The control plane blocks skill installation and runtime loads that skip the proxy; egress and proxy policy are the hard boundary.

Exception / approval path

Research use in an isolated sandbox with no company data or credentials, recorded as a sandbox load; promotion to any shared environment goes through the proxy and scan.

Test permitted, changed and denied paths
Should remain permitted

Load a scanned, digest-pinned safetensors model from the internal proxy, or install a skill from the internal reviewed catalogue.

Should be blocked or held

Load an unscanned pickle model, install an unreviewed skill from a marketplace, or pull a model by floating tag directly from the hub.

High severitySA-06
06

Review vendor AI features that process company data

Require approval
Policy statement

Hold enablement of an AI feature inside a sanctioned SaaS product, and hold OAuth grants from AI applications to company data, until the data-processing terms, training opt-out, retention and tenant isolation have been reviewed and recorded. A feature a vendor switches on by default is treated as a new processor.

Covered operations
  • Enable a vendor AI assistant, summariser or copilot for a tenant, workspace or team
  • Approve an OAuth or app consent request from an AI application for mail, files, chat or CRM scopes
  • Accept updated vendor terms that add model training or third-party processing
  • Connect a sanctioned SaaS tenant to an external model provider
Applicable tools & systems
Microsoft 365Google WorkspaceSlackSalesforceZoomNotionAtlassianIdentity providers (Entra ID, Okta)
Microsoft 365Enable a third-party AI summariser for all Teams meetings

Hold for data-protection review and inventory entry.

Google WorkspaceUser consents to an AI note-taker requesting read access to all Drive files

Block user consent; route to admin consent workflow.

SalesforceSwitch on a generative feature that sends CRM records to an external model

Hold until processing terms and region are recorded.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the vendor, product, feature, model provider, processing region, training opt-out state and the data scopes the feature can read.
  • Hold tenant-wide AI feature enablement until a named data-protection reviewer records the assessment; block user-level consent to AI applications requesting broad scopes.
  • Re-evaluate when the vendor changes the model provider, adds scopes or changes terms; the earlier approval does not carry over.
  • Record every enabled AI feature and consented AI application in the inventory so shadow AI discovery has a sanctioned baseline to compare against.

Enforce at

Use identity-provider app consent policies, SaaS admin controls and cloud app discovery to gate features and grants. The control plane records the approved feature and scope set; the consent policy and vendor admin setting are the hard boundary.

Exception / approval path

A workspace-scoped pilot with synthetic or public data, recorded in the inventory with an end date; production data requires the full review.

Test permitted, changed and denied paths
Should remain permitted

Enable a reviewed feature for the approved workspace with the recorded scopes and training opt-out in place.

Should be blocked or held

Enable an unreviewed vendor AI feature tenant-wide, approve a broad-scope AI app consent at user level, or accept new training terms without review.

High severitySA-07
07

Allow sanctioned AI tools through the approved route, with a record

Allow with record
Policy statement

Permit AI assistants, agents, connectors and models that are on the sanctioned inventory and reached through the approved tenant, gateway or proxy, and record the actor, tool, version and action for every session so the organisation can answer who did what through which tool.

Covered operations
  • Use a sanctioned assistant under the enterprise tenant
  • Call a registered MCP server through the gateway
  • Load a scanned, pinned model or skill from the internal catalogue
  • Run an agent action inside its approved permission set
Applicable tools & systems
GitHub CopilotClaudeCursorMicrosoft CopilotTracelet MCP gatewayInternal model catalogueIdentity providers (Entra ID, Okta)SIEM
GitHub CopilotGenerate code in a repository under the enterprise tenant with content exclusions applied

Allow and record the session and version.

Tracelet MCP gatewayCall a registered ticketing tool with a per-user credential

Allow and record actor, tool and matched policy.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve the tool, version, tenant and route for every action; a sanctioned tool reached outside its approved route (personal login, direct server URL, direct hub download) is not sanctioned for that action.
  • Record actor, effective identity, tool, version, matched policy and outcome at decision time; minimise captured content and keep the record outside the acting identity’s control.
  • Reconcile the record against shadow AI discovery (browser, network, identity-provider consent logs) so tools seen in traffic but absent from the inventory are surfaced for intake.
  • Re-evaluate a sanctioned tool when its version, publisher, permissions or model provider changes.

Enforce at

Keep the sanctioned inventory as the source of truth and forward decision records to the SIEM. Discovery from browser management, cloud app discovery and identity-provider consent logs closes the gap between what is sanctioned and what is running.

Exception / approval path

None needed; this policy is the sanctioned path. Adding a tool to the inventory goes through the AI tool intake process.

Test permitted, changed and denied paths
Should remain permitted

Use an inventoried tool through its approved route and confirm a decision record exists for the action.

Should be blocked or held

Use the same tool through a personal login or a direct endpoint; the action is evaluated by SA-01 to SA-05, not allowed under this policy.

07 / 09 · Control domain

Payments & financial operations

Use agents for reconciliation and workflow preparation without allowing autonomous payments, bank-detail changes, excessive refunds or changes to posted books.

5 policies21 applicable systemsOwners: Financial controller + treasury or payments ownerDownload pack .md
Control scope and what to configure first
Protected assetsBank accounts, payees, payment instructions, refunds, ledgers, close periods and merchant routing
Consequential actionsPayee change, money movement, refund, write-off, journal mutation and payment configuration change
Applicable systemsERP, treasury, expense, payroll and payment-provider platforms
Context to resolve
Resolve legal entity, live/test mode, actor, payee history, bank fingerprint, amount, currency, cumulative exposure, invoice and approval chain.
Authoritative boundary
Keep payment execution and master-data credentials outside general assistants. Execute through the finance system’s maker-checker workflow and preserve its immutable transaction record.
Configure first
  • Legal entities, live versus test tenants, currencies, payees and delegated authority thresholds
  • Two-person approval matrix, new-payee cooling period and sanctions/fraud checks
  • Closed accounting periods, protected ledgers and payment-provider configuration owners
Policy set

Policies in this domain.

5 of 5 policies
Critical severityFO-01
01

Block autonomous payee and bank-detail changes

Block
Policy statement

Deny agents from directly creating payees or changing bank account, beneficiary, wallet or payout details in a live financial system.

Covered operations
  • Create or activate payee/vendor
  • Change bank routing, account, IBAN, wallet or payout destination
  • Alter verification status or bypass cooling period
Applicable tools & systems
SAPOracle ERPNetSuiteMicrosoft Dynamics 365WorkdayStripe ConnectAdyenTreasury platforms
ERPReplace vendor bank account using details from an inbound email

Block direct execution.

Stripe ConnectChange a live connected account payout destination

Block and use verified human workflow.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve legal entity, payee master record, previous destination fingerprint, verification source and actor.
  • Treat a bank-detail change followed by payment as one high-risk sequence, even across systems or sessions.
  • Do not accept instructions or verification evidence solely from the same email, document or chat being acted upon.

Enforce at

Keep supplier/payee master-data authority outside agent credentials. Route changes through verified call-back, maker-checker and cooling-period controls in the system of record.

Exception / approval path

No direct agent exception. Two authorised humans verify through an independent channel and execute in the finance workflow.

Test permitted, changed and denied paths
Should remain permitted

Prepare a payee-change request with redacted comparison data for human verification.

Should be blocked or held

Apply the change, bypass verification or submit a payment to the newly supplied destination.

Accountable ownerTreasury or accounts-payable master-data owner
Critical severityFO-02
02

Require two-person approval for consequential money movement

Require two-person approval
Policy statement

Hold payment, transfer, payout, payroll or disbursement instructions that involve a new payee, exceed delegated value or velocity limits, or create material cumulative exposure.

Covered operations
  • Create, approve, release or schedule payment
  • Transfer between accounts or initiate payout
  • Run payroll or bulk disbursement
  • Retry or split transactions after decline/hold
Applicable tools & systems
SAPOracle ERPNetSuiteStripeAdyenPayPal / BraintreeBanking portalsPayroll platforms
NetSuite / ERPRelease a $250,000 payment batch

Hold for two-person approval.

StripeRetry a payout request with a new idempotency key

Hold as a potential duplicate.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve live/test mode, legal entity, amount/currency, base-currency value, payee history, destination fingerprint and supporting obligation.
  • Aggregate by payee, actor and time window to prevent threshold splitting and duplicate payment.
  • Require two eligible approvers, neither the requester, and preserve the destination system’s maker-checker control.
  • Use idempotency and duplicate detection; a retry must reference the original transaction intent.

Enforce at

Use a finance-owned execution identity, destination-native dual approval, transaction limits and idempotency/duplicate controls. The agent can prepare but cannot be a maker and checker.

Exception / approval path

Emergency payment follows the documented financial authority matrix; approval binds to payee fingerprint, amount, currency and transaction identifier.

Test permitted, changed and denied paths
Should remain permitted

Create a draft payment within preparation permissions without releasing funds.

Should be blocked or held

Release without two approvers, split around limits, change payee after approval or create a duplicate via retry.

Accountable ownerTreasury or payments owner
High severityFO-03
03

Review refunds, credits and write-offs beyond delegated authority

Require approval
Policy statement

Hold refunds, service credits, credit notes and write-offs that exceed the operator’s single-action or cumulative limit, lack a valid source transaction, or change destination.

Covered operations
  • Create refund or credit note
  • Write off receivable or waive fee
  • Issue manual credit outside the original payment path
  • Repeat partial actions that cumulatively exceed authority
Applicable tools & systems
StripeAdyenPayPal / BraintreeSalesforceZendeskNetSuiteSAPOracle ERP
StripeRefund the full live charge after two prior partial refunds

Hold when cumulative amount exceeds authority.

ERPWrite off a receivable with no linked dispute or approval

Hold.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve original transaction, customer/tenant, amount remaining, currency, reason code and refund destination.
  • Aggregate by operator, customer and original charge to detect split or duplicate credits.
  • Require approval for destination changes and never send a refund to unverified alternate payment details.

Enforce at

Use provider/ERP roles, cumulative limits and a broker that links the decision to the original transaction. Record the downstream refund or credit identifier.

Exception / approval path

Approval covers source transaction, total cumulative value, destination and reason; changed values require reapproval.

Test permitted, changed and denied paths
Should remain permitted

Issue one valid refund within delegated authority to the original payment method.

Should be blocked or held

Change destination, exceed cumulative limit, refund more than the remaining amount or reuse approval for another charge.

Accountable ownerRevenue or support finance owner
Critical severityFO-04
04

Block deletion or silent rewrite of posted financial records

Block
Policy statement

Deny deletion, overwrite or backdating of posted journals, settled transactions, invoices and audit records, and deny reopening a closed period through an agent identity.

Covered operations
  • Delete or edit posted journal/transaction
  • Reopen or change close status of accounting period
  • Backdate record into a closed period
  • Delete reconciliation or audit evidence
Applicable tools & systems
SAPOracle ERPNetSuiteMicrosoft Dynamics 365XeroQuickBooks OnlineWorkday Financial Management
ERPDelete a posted journal from the closed quarter

Block; use reversal workflow.

Accounting platformReopen FY26-Q4 to backdate an adjustment

Block direct agent execution.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve legal entity, ledger, posting status, close period, source transaction and audit implications.
  • Require corrections through reversal and compensating entry, preserving linkage to the original.
  • Keep period-close and audit-record administration outside the agent’s finance role.

Enforce at

Use ledger permissions, close locks, append-only audit records and correction workflows in the financial system. Monitor attempts from all API and UI paths.

Exception / approval path

Period reopening is a controller-led workflow with documented rationale, independent approval and auditor-visible record; not an agent override.

Test permitted, changed and denied paths
Should remain permitted

Prepare a reversing journal in an open period for authorised review.

Should be blocked or held

Delete or overwrite the original, reopen the period or remove evidence of the change.

Accountable ownerFinancial controller
Critical severityFO-05
05

Require dual control for live payment-routing configuration

Require two-person approval
Policy statement

Hold changes to live merchant accounts, settlement destinations, webhook endpoints, signing secrets, fraud rules and payment-routing configuration.

Covered operations
  • Change settlement bank or merchant ownership
  • Rotate/reveal webhook signing secret or change endpoint
  • Change fraud thresholds, routing rules or live/test mode
  • Disable reconciliation or notification controls
Applicable tools & systems
StripeAdyenPayPal / BraintreeCheckout.comBanking gatewaysERP payment connectorsFraud platforms
Payment providerPoint live webhooks at a new domain and reveal a new signing secret

Hold for payments and security approval.

Merchant portalChange settlement destination for the production entity

Hold for dual control.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve platform account, legal entity, live/test mode, current and proposed destination/configuration and downstream dependencies.
  • Require payments and security/finance approval where credential, routing or fraud posture changes.
  • Bind approval to the exact configuration diff and verify post-change callbacks/reconciliation.

Enforce at

Use provider-native restricted roles and approval where available; otherwise broker writes through a finance/security-owned service and verify the resulting configuration independently.

Exception / approval path

Incident changes remain dual-controlled, exact-diff approved and time-bound with mandatory post-change verification.

Test permitted, changed and denied paths
Should remain permitted

Read live configuration or change test-mode routing within delegated scope.

Should be blocked or held

Change live settlement, weaken fraud controls, reveal signing material or alter approved values before execution.

Accountable ownerPayments platform owner + financial controller
08 / 09 · Control domain

Customer actions & communications

Let agents research, draft and resolve routine work while requiring accountable review for broad communications, account-impacting changes and commercial commitments.

5 policies26 applicable systemsOwners: Customer operations owner + communications or commercial ownerDownload pack .md
Control scope and what to configure first
Protected assetsCustomer accounts, cases, entitlements, CRM records, audiences and public content
Consequential actionsCross-tenant lookup, suspension/deletion, bulk send, publication, discount and commitment
Applicable systemsCRM, support, email, CMS, social, messaging and contract platforms
Context to resolve
Resolve operator, customer/tenant, assigned case, target account, recipient snapshot, exact content, channel, authority and cumulative value.
Authoritative boundary
Use tenant-aware APIs, least-privileged sending identities, native publish roles and commercial approval workflows. A reviewed draft is not permission to send or commit.
Configure first
  • Customer/tenant boundaries, assigned cases, account owners and authorised support actions
  • External channels, audience-size thresholds, sending identities and approved content versions
  • Delegated discount, credit, entitlement and account-lifecycle authority
Policy set

Policies in this domain.

5 of 5 policies
High severityCA-01
01

Review bulk external sends and public publication

Require approval
Policy statement

Hold production email/SMS sends, external-channel posts and public publication when they exceed the configured audience threshold or use a company publishing identity.

Covered operations
  • Send or schedule campaign/broadcast
  • Publish or schedule CMS/social content
  • Post to public or external shared channel
  • Resend, change segment or swap content after approval
Applicable tools & systems
MailchimpHubSpotSalesforce Marketing CloudGmail / Microsoft 365TwilioWordPress / ContentfulSlack / TeamsSocial platforms
MailchimpSend campaign launch-2026 to 180,000 contacts

Hold for campaign-owner approval.

WordPressChange an approved draft to status=publish after editing claims

Hold again.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve recipient snapshot, count, customer segment, exclusions, sender, channel, exact content/attachments and schedule.
  • Approval binds to content and recipient digests plus sending identity; draft approval is not send approval.
  • Aggregate split sends and require new approval for materially changed content, audience or timing.

Enforce at

Separate drafting from sending/publishing credentials. Gate the native send/publish operation and verify audience plus content immediately before execution.

Exception / approval path

Approval covers exact content, audience snapshot, channel, sender and schedule with a short expiry.

Test permitted, changed and denied paths
Should remain permitted

Save a draft or send a test only to the approved internal test list.

Should be blocked or held

Send to a real audience without approval, change the segment/content or split a large broadcast into smaller sends.

Accountable ownerCommunications or campaign owner
Critical severityCA-02
02

Block customer actions outside the assigned tenant or case

Block
Policy statement

Deny customer-account reads and mutations unless the target tenant and account are bound to the operator’s assigned case, account scope or approved support role.

Covered operations
  • Read or update customer profile/account
  • Reset credential, change security setting or view diagnostic data
  • Add internal note or public reply to a different tenant’s case
Applicable tools & systems
ZendeskIntercomSalesforceHubSpotServiceNowJira Service ManagementInternal customer-admin tools
ZendeskUse customer ID from another ticket to retrieve account details

Block.

SalesforceUpdate an account outside the seller’s assigned territory

Block unless a separately authorised role applies.

Evaluation rules & enforcement

Evaluate these conditions

  • Derive tenant and case assignment from signed source-system context; ignore model-supplied tenant claims.
  • Enforce row/object-level access on every related-object traversal and tool call.
  • Fail closed when account-to-case mapping is missing or ambiguous.

Enforce at

Use tenant-aware service APIs, scoped integration identities and source-system entitlements. Never expose a global customer-admin credential to the assistant.

Exception / approval path

A named escalation role may access specified tenants for a case and duration; approval does not grant global reusable access.

Test permitted, changed and denied paths
Should remain permitted

Read the minimum account fields for the customer attached to the assigned case.

Should be blocked or held

Swap account ID, follow a relationship across tenants or act on an account with no assignment context.

Accountable ownerCustomer systems owner
Critical severityCA-03
03

Require approval for destructive customer-account actions

Require approval
Policy statement

Hold deletion, irreversible anonymisation, suspension, security reset or bulk entitlement removal for a live customer account.

Covered operations
  • Delete/anonymise customer or tenant
  • Suspend account or terminate active sessions
  • Remove all entitlements, domains or API credentials
  • Bulk destructive action across accounts
Applicable tools & systems
Internal customer-admin toolsSalesforceZendeskAuth0 / Okta Customer IdentityStripe BillingSaaS entitlement systems
Internal adminDelete tenant acme-prod and all associated data

Hold for account and data-owner workflow.

Okta / customer identityReset MFA and sessions for every user in one enterprise tenant

Hold.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve exact customer/tenant, account owner, case/request, regulatory retention and recoverability.
  • Expand bulk selectors and identify strategic, protected or multi-entity accounts.
  • Bind approval to action, target, reason and recovery window; changed action or target invalidates it.

Enforce at

Use a customer-operations broker with soft-delete/recovery where possible, exact-target confirmation and native audit. Keep irreversible delete authority separate from normal support tools.

Exception / approval path

Security containment may suspend access with incident approval; permanent deletion still follows retention and account-owner review.

Test permitted, changed and denied paths
Should remain permitted

Disable one compromised token or perform a reversible action within documented support authority.

Should be blocked or held

Delete/suspend the wrong tenant, change target after approval or remove all access using a broad selector.

Accountable ownerCustomer account owner + customer operations
High severityCA-04
04

Review discounts, credits and commercial commitments

Require approval
Policy statement

Hold discounts, pricing changes, service-level promises, renewal terms and non-standard commitments that exceed the operator’s delegated authority or approved playbook.

Covered operations
  • Change quote price, discount or commercial term
  • Commit to service level, delivery date, warranty or liability term
  • Issue service credit or free entitlement
  • Send final proposal containing non-standard terms
Applicable tools & systems
Salesforce CPQHubSpotMicrosoft Dynamics 365Gmail / Microsoft 365DocuSignIroncladDeal-desk platforms
Salesforce CPQSet a 45% discount where delegated authority is 15%

Hold for commercial approval.

EmailPromise a contractual 99.999% SLA in a final customer message

Hold for legal/service-owner review.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve opportunity/account owner, product, currency, list price, cumulative discount, term version and approval matrix.
  • Detect commitments in free text as well as structured quote fields.
  • Approval binds to exact document/content version and structured commercial values.

Enforce at

Use CPQ/contract authority matrices and a send/sign gate tied to the exact proposal version. Agents may draft but cannot create binding acceptance or override pricing controls.

Exception / approval path

Approval covers the named account, exact values and document digest; changes require a new decision from the appropriate authority.

Test permitted, changed and denied paths
Should remain permitted

Prepare a standard quote within documented discount authority.

Should be blocked or held

Increase discount, add non-standard terms after approval or send a binding offer under a different account.

Accountable ownerDeal desk or commercial owner
High severityCA-05
05

Review broad entitlement and licensing changes

Require approval
Policy statement

Hold changes that grant premium capabilities, remove contracted access, alter seat counts materially or change an enterprise customer’s plan outside a verified order or support entitlement.

Covered operations
  • Upgrade/downgrade plan or change billing entitlement
  • Grant premium/admin feature
  • Remove seats or licensed capability in bulk
  • Extend trial or service beyond delegated value
Applicable tools & systems
Stripe BillingSalesforceChargebeeZuoraInternal entitlement servicesCustomer support platforms
Stripe BillingMove enterprise tenant from 100 to 1,000 seats without an order

Hold.

Internal adminDisable a contracted security feature for the whole tenant

Hold for customer owner approval.

Evaluation rules & enforcement

Evaluate these conditions

  • Resolve contract/order, customer tenant, current and proposed entitlement, monetary impact, effective date and requester authority.
  • Aggregate repeated extensions and per-seat changes against delegated limits.
  • Require account/billing owner approval for material or contract-inconsistent changes.

Enforce at

Gate entitlement writes through an order/support-aware service and compare to contract state. Record the resulting subscription/entitlement version.

Exception / approval path

Approval covers tenant, exact entitlement delta, value and expiry; permanent exceptions must be reflected in the commercial system of record.

Test permitted, changed and denied paths
Should remain permitted

Apply a documented, low-value support extension within delegated authority.

Should be blocked or held

Grant uncontracted premium access, remove contracted features or split extensions around limits.

Accountable ownerBilling or customer account owner

Bring the decision baseline with you.

These controls depend on resolved targets, fail-closed ambiguity, action-bound approval and an evidence-grade record.

Review the shared baseline
Make it real

Inventory. Simulate. Enforce.

A serious policy is more than a keyword match. It resolves the identity, target, environment and blast radius, then verifies the downstream result.

Read the rollout guide
  1. Attach authoritative context.Inventory immutable resource IDs, production classification, owners and delegated authority.
  2. Test evasions and changed requests.Cover aliases, APIs, batches, encoded content, split actions, retries and approval invalidation.
  3. Back it with destination controls.Use database permissions, cloud IAM, repository rules and native approval, not only agent interception.

These are enterprise control patterns, not deployable Tracelet configuration or legal advice. Tool names show where a policy may apply; they do not claim every connector or action ships today. Replace example thresholds and approval windows with your own, verify tool and action coverage, and keep the authoritative deny or permission boundary in the destination system.

How these controls are designed

Each policy begins with a real failure mode, resolves the effective identity and target, and then makes a fail-closed decision with an accountable owner. The model is informed by NIST Zero Trust Architecture and OWASP guidance on excessive agency and sensitive information disclosure .

Design partners

Start the conversation. One call to establish fit and how we would work together.

Become a design partner