Hidden AI features were impossible to ignore when Claude Code's source became public on March 31, 2026: fully-built systems were sitting in the shipped binary behind compile-time flags, without clear user-facing notice. This article uses that moment as a case study for the governance gap — policies written against visible behaviour while hidden AI features can change autonomy, memory, and orchestration risk overnight.
Key Takeaways
- Treat hidden AI features as a first-class vendor risk: your policy must assume capabilities may exist beyond the marketing surface.
- Add contract language that requires notice before meaningful activation of new model or product behaviour — especially autonomy, memory, or orchestration.
- Run periodic reviews using a simple AI usage audit workflow and keep an AI tool register current.
- When undisclosed capabilities become public (for example via the Claude Code leak analysis), trigger your AI incident response playbook review — even if no customer data escaped.
- Align acceptable use to all present capabilities, not only documented ones — start from our AI acceptable use policy template.
Summary
Hidden AI features are not rare engineering curiosity — they are standard release practice (feature flags, staged rollouts, kill switches). The governance problem is information asymmetry: procurement and policy teams document what vendors advertise, while engineering ships more. For lean teams, the fix is lightweight: broader policy scope, vendor notice clauses, and disciplined reviews — without pretending you can eliminate flags.
Governance Goals
- Make “approved vs not approved” coverage explicit for hidden AI features that could change autonomy, data retention, or multi-agent behaviour.
- Ensure vendors cannot silently widen the risk surface without a recorded decision on your side.
- Keep an evidence trail suitable for audit: what you knew, when you learned it, and what you changed.
Risks to Watch
Autonomy drift. A hidden AI features stack might include classifiers that approve tool actions without user confirmation — your policy may assume prompts always gate risky operations.
Retention drift. Persistent memory or “consolidation” systems change data lifecycle assumptions; privacy reviews based only on chat sessions can miss long-lived state.
Orchestration drift. Coordinator or multi-agent modes blur accountability: which component produced output, and which log line matters for investigation?
Compliance mismatch. If regulators or customers ask what tooling you run, “we use vendor X chat” may be incomplete when undisclosed modules exist in the same binary.
Controls (What to Actually Do)
Vendor notice clause. Require written notice before activation of capabilities that affect autonomy, retention, or cross-system integration. Define “significant” in plain language.
Policy scope. State that your acceptable use rules apply to all capabilities present in approved packages — not only documented UI features.
Tool inventory + delta review. On each renewal or quarterly review, ask what changed under the hood; use your tool register to record answers.
Incident hook. Treat credible disclosures of undisclosed capability as a vendor incident — see AI incident response playbook for a lightweight workflow.
Checklist (Copy/Paste)
- Contract or order form includes notice-before-activation language for material capability changes.
- Acceptable use policy states coverage of undocumented or disabled-but-present modules.
- Register lists each AI tool, owner, data classes, and last review date.
- Run-through of audit workflow scheduled with calendar invite.
- Security news feed includes vendors in active use; items route to a single owner.
Implementation Steps
- Baseline (week 1). Export the list of AI tools in active use; owners confirm deployment channel (CLI, IDE, SaaS).
- Policy patch (week 1–2). Amend acceptable use with “all capabilities in artifact” language using the template above.
- Vendor pass (week 2–3). Send a short, written questionnaire about feature flags, telemetry, and notification practice; store answers with the register.
- Operationalize (week 4). Add vendor security headlines review to an existing security stand-up; rehearse one tabletop using the incident playbook.
- Measure (ongoing). Count review completion and time-to-decision after a public disclosure; tighten templates if reviews stall.
Frequently Asked Questions
Q: What counts as a “hidden” feature versus an unreleased roadmap item?
A: If the capability is already in the binary or package you deploy — even off by default — it is present risk surface. Roadmap slides are not; shipped code is.
Q: Do we need legal to renegotiate every SaaS tool?
A: No. Document expectations in your register, and push formal clauses where spend or data sensitivity warrant it. The goal is consistent decisions, not perfect contracts everywhere.
Q: How do we avoid blocking engineering velocity?
A: Use narrow triggers: autonomy, data retention, and cross-system orchestration. Everything else can be FYI-level tracking until risk changes.
Q: What if the vendor refuses to answer?
A: Record the refusal, raise risk tier, and restrict data classes or environments for that tool until you get clarity.
Q: How does this relate to the Claude Code disclosure specifically?
A: It is a worked example of hidden AI features in a real artifact; use it internally as a case study when training builders — and read the full incident write-up alongside this guide.
Why vendors ship hidden AI features behind feature flags
Vendors use flags for gradual rollout, kill switches, and A/B testing. None of that is automatically nefarious. The governance issue is when materially risk-changing behaviour sits behind a switch users cannot see — and policies assume it does not exist.
The Three Categories of Hidden Features That Matter
Autonomous decision-making. Features that approve actions without user prompts change your control model.
Persistent memory. Cross-session state changes deletion, minimization, and breach narratives.
Orchestration / multi-agent modes. These complicate logging, attribution, and escalation paths.
What Your Governance Policy May Be Missing
Most policies list approved tools and disallowed data classes. They often omit: undisclosed modules, activation change management, and vendor-to-customer notification paths. Close that gap with the controls above — and pair policy work with operational reviews, not slide decks alone.
Four Changes to Make to Your AI Policy and Vendor Agreements
Add notice requirements, broaden acceptable-use scope, bake feature inventory into periodic review, and treat significant undisclosed discoveries as incidents. Each step links back to templates and workflows cited earlier so your team spends time on decisions, not formatting.
Operational note for lean teams
You do not need a heavyweight enterprise procurement office to execute the four changes. A single owner — usually engineering management plus a security or operations counterpart — can run the vendor pass in a morning, store answers beside the tool register, and route exceptions to leadership in a one-page summary. The objective is forward motion with evidence, not perfection. When hidden AI features surface through research rather than vendor disclosure, prefer written questions over verbal assurances; the record is what makes the next incident review boring instead of chaotic.
The deeper problem with hidden AI features in production tools
Hidden AI features are one face of a wider opacity problem: documentation lags binaries. Small teams win by assuming less transparency than they wish they had — and building governance that still works under that constraint.
References
- Primary incident context and governance lessons: What the Claude Code Source Leak Reveals About AI Tool Governance.
- U.S. NIST AI Risk Management Framework (authority background): https://www.nist.gov/itl/ai-risk-management-framework
- EU AI Act resource hub (regulatory framing): https://artificialintelligenceact.eu/the-act/
- Practical review cadence: AI usage audit workflow for small teams.