TL;DR: The fastest way to put AI to work is to govern it, not to loosen controls, according to Willow, and it describes July changes including Claude Code rollout management, custom admin roles, guard rules that pause risky tool calls, MDM-managed Chrome protection, and CrowdStrike log delivery. The pattern is that control precision, not open access, is what makes broader AI enablement workable.
At a glance
What this is: Willow’s July digest frames AI rollout as a governance problem, highlighting controls for Claude Code deployment, admin scoping, human approval, managed browser protection, and log delivery.
Why it matters: It matters because teams moving AI into production need to govern access, approval, and observability at the same pace as adoption, or they will default to either blocking capability or over-trusting it.
Context
The core problem is not whether AI can be deployed, but whether it can be governed well enough to move beyond pilot mode without creating unmanaged access paths. In practice, that means separating capability rollout from privilege, approval, and logging decisions so security teams can control use without freezing adoption.
Willow’s July digest uses Claude Code, admin delegation, guard rules, managed browser protection, and SIEM logging to show the same governance gap from several angles. The common theme is that AI tooling becomes operational only when policy, identity, and oversight are designed together.
Key questions
Q: How should security teams govern shadow AI without slowing adoption?
A: Start with continuous discovery, then classify tools by data access, system connectivity, and provider trust. Use policy thresholds that allow low-risk use cases quickly while forcing review, restriction, or blocking for tools that can reach sensitive systems. The control objective is to make safe adoption fast and unsafe adoption expensive.
Q: Why do broad admin roles create risk in AI platforms?
A: Broad roles collapse operational work and security authority into one account, which makes it easy to overgrant access and hard to prove who can change what. In AI environments, that affects policy, connectors, logs, and deployments at once, so role design must be granular.
Q: What should teams do when a risky AI action needs review before execution?
A: Use a pause-and-approve workflow that stops the action before it runs and routes the decision to a human reviewer. That approach is stronger than either full blocking or unconditional allow, because it preserves business use while retaining decision control.
Q: How do organisations know whether AI governance is actually working?
A: AI governance is working when teams can prove that data access, identity permissions, and runtime controls line up with policy in practice. A useful test is whether the organisation can answer who accessed what, through which identity, and whether any out-of-policy movement was blocked or detected in time.
Technical breakdown
Governed rollout is different from software rollout
AI rollout is not just distribution. When a tool like Claude Code is deployed across an organisation, the real issue is who can enable it, where it runs, what settings apply, and which actions are allowed under policy. That is why rollout controls need to include environment scoping, admin boundaries, and auditability. Without those, deployment speed increases faster than governance maturity, and the organisation gets broader exposure before it gets better control. The mechanism matters because AI tooling often crosses endpoint, browser, and cloud policy layers at once. See the AI Coding Agents Security Guide.
Practical implication: Treat AI rollout as an identity and policy exercise, not a software install exercise.
Why scoped admin roles matter for AI operations
Custom admin roles address a common failure mode in identity governance: the overuse of broad administrative access. If one person needs to manage connectors or skills, that does not mean they should also control policy settings, rollout settings, or security boundaries. Fine-grained roles reduce unnecessary standing privilege and make administrative authority easier to audit. The important technical point is that effective scoping must apply beyond the user interface and across API endpoints, or governance gaps simply move behind the scenes.
Practical implication: Model AI platform administration as privilege segmentation, not a single super-admin function.
Human approval is a control, not a compromise
Guard rules that pause a risky tool call before execution introduce a governance pattern that is often missing in AI operations: pre-execution review. This is not the same as blocking everything, and it is not the same as fully trusting automation. It creates a decision gate when the model or agent reaches a sensitive action, which preserves capability while reducing the chance of irreversible behaviour. In governance terms, that is closer to just-in-time approval than to blanket allow or deny logic, and it is one of the few mechanisms that can fit real operational tempo. See the AI Governance Guide.
Practical implication: Use approval gates where the business needs speed but the action still deserves review.
NHI Mgmt Group analysis
AI governance fails when organisations treat access as a binary choice. Willow’s digest shows that the real operational problem is not whether to enable AI, but how to govern it without forcing teams into all-or-nothing decisions. That is a governance design issue, not a product feature issue. The field should read this as evidence that policy precision is now a prerequisite for practical AI adoption.
Scoped administration is becoming the baseline for AI platform control. Broad admin rights do not scale when AI systems touch connectors, policies, browser extensions, logs, and approval paths. The stronger model is to separate operational administration from security authority so the people who run the platform do not automatically control its risk posture. This is a standard IAM lesson, but AI platforms make the cost of ignoring it much more visible.
Pre-execution approval is the control that turns AI from tolerated to governable. A pause-and-approve step changes the risk profile because the organisation can intervene before a tool call executes, not after the outcome is already in motion. That matters most where the action is reversible in theory but costly in practice. The field should stop treating approval as friction and start treating it as the control that keeps AI usable under policy.
Managed deployment only works when the control plane reaches the whole estate. MDM-based rollout for browser protection and centralised log delivery both point to the same lesson: partial coverage is not governance. If controls apply to some devices, some logs, or some workflows, then the residual unmanaged surface is still large enough to matter. The practical conclusion is that AI governance has to be fleet-wide and observable, or it remains aspirational.
From our research library:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
- Read next: AI Coding Agents Security Guide
What this signals
Control precision is becoming the practical test for AI governance. Teams no longer need to choose between disabling AI and trusting it blindly. They need policy layers that can distinguish routine use from risky action, because that is what lets AI move from pilot to production without widening the attack surface.
A fleet-wide approach matters more than isolated controls. If browser protections, log delivery, and admin scoping do not reach every managed endpoint and every privileged workflow, the governance model stays fragmentary and the exceptions become the real operating model.
Willow’s July digest also reinforces a broader pattern: AI adoption is now constrained less by capability than by whether the organisation can make human review and policy enforcement part of the runtime path.
For practitioners
- Define AI rollout tiers Separate pilot, limited production, and full production states so policy changes, approval requirements, and admin scopes move in a controlled sequence.
- Scope administrative access tightly Assign custom roles for AI platform administration so connectors, policy settings, and security controls are not bundled into one broad privilege set.
- Use pre-execution approval for risky tool calls Configure guard rules so sensitive actions pause for human sign-off before execution instead of relying on post-action review.
- Push protection through managed device controls Use MDM to distribute browser-based AI protections across managed endpoints so coverage is consistent instead of dependent on user installation.
- Send AI logs to the security stack Route platform logs into the SIEM and test delivery so security operations can verify that AI activity is visible where analysts already monitor alerts.
Key takeaways
- Willow’s July digest frames AI adoption as a governance problem, not a raw capability problem.
- The central operational theme is control precision, especially around admin scope, approval gates, and observable logging.
- Teams that want faster AI rollout need policy and identity controls that scale with deployment instead of lagging behind it.
Related NHI Mgmt Group resources: AI Coding Agents Security Guide · AI Governance Guide · Okta Security Hardening Guide · AI Security Maturity Model
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The digest centres on scoped AI administration and governed tool execution, both core privilege concerns. |
| ASI02 — Tool Misuse | Guard rules that pause risky tool calls address misuse of tools at runtime. | |
| Recommendation — Limit AI platform privileges to the smallest viable role set and separate policy control from operational administration. Gate sensitive tool actions with approval before execution when the action could cause irreversible impact. | ||
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | Custom admin roles and connector scoping reduce broad standing privilege in AI-related access. |
| NHI-10 — Human Use of NHI | Human approval and managed governance describe how people supervise non-human actions and access. | |
| Recommendation — Reduce standing privilege for AI operators and administrators to only the functions each role genuinely needs. Keep humans in the approval loop for sensitive non-human actions and define when that supervision is mandatory. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governing AI use through roles, policy, and oversight. |
| Recommendation — Establish clear accountability, review gates, and policy ownership for every AI deployment stage. | ||
Key terms
- AI Governance: AI governance is the set of controls used to discover, classify, approve, restrict, monitor, and revoke AI-enabled access. It connects identity, data, and policy so organisations can manage what AI can reach, what it can share, and when it should be stopped.
- Scoped administration: An administration model in which privileged users receive only the specific functions needed for their job instead of broad platform-wide control. For AI systems, this reduces the chance that operational convenience becomes unnecessary authority over policy or security settings.
- Pre-execution Authorization: Pre-execution authorization is a control pattern where the system checks whether an action is allowed before the action runs. For AI agents and other NHIs, this reduces the chance that a credential can be used to complete an unsafe task and creates a clearer enforcement boundary than logging alone.
- Managed device: A managed device is an endpoint enrolled in organisational controls for inventory, patching, policy enforcement, and monitoring. In AI governance, it matters because endpoint control is often the last enforceable barrier before sensitive data leaves the environment.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org