Your controls can stay correct while your environment becomes ungoverned
A platform gains a new behavior. No administrator changed a setting. But the environment can now do something it could not do when it was approved, and the original assessment no longer covers it. This is capability drift.
An enterprise enables an AI assistant across its collaboration platform. The rollout is reviewed carefully. Identity, data access, logging, retention, approval, and usage controls are all configured correctly. Everything passes.
A few months later, the platform provider ships a new capability: users can now upload custom agents, or agent code. No enterprise setting changed. No control was disabled. No configuration drifted. Yet the environment can now do something it could not do when it was originally approved.
What actually changed
Not a setting. The reachable execution graph. The original environment supported one path:
AI assistant → enterprise data → user response
The updated environment may now support a much longer one:
AI assistant → uploaded agent → delegated access → tools → enterprise data → external actions
Every new hop is a question the original assessment never asked:
- Who can upload an agent?
- What identity does it run under?
- What data can it reach?
- Can it call tools or external services?
- Can it persist instructions or memory?
- Does it require human approval?
- Is any of this covered by the original review?
- Do controls even exist for this new execution path?
Traditional monitoring can still report every existing control as healthy, because every existing control is healthy. Nothing failed. The environment changed.
This is capability drift, not configuration drift
Configuration drift is when a setting quietly changes from its approved state. Capability drift is different, and harder to catch: no setting changed at all. The platform gained a new behavior, and that behavior changed what the enterprise can do. A posture that was assessed against one reachable graph is now running against a larger one.
The corpus already names this failure
Two controls in the open corpus are written for exactly this shape:
AB-10 · Transitive Reachable-Graph Mapping
Map the full set of tools, data, agents, and external systems an AI can reach, transitively, so the environment you assess is the environment that can actually act.
EV-14 · Evaluation validity bound to the deployed reachable graph
An evaluation verdict is valid only for the model-plus-reachable-graph it was produced against, up to a declared material equivalence. A material change to that graph invalidates it, flipping the standing verdict to inconclusive until coverage is recomputed.
EV-14 is the capability-drift control stated plainly: your prior approval expires when the reachable graph materially changes. The new execution path then has its own controls to answer, drawn from the Agentic, Identity, and Authority domains, agent identity, task-scoped delegation, tool authorization, memory validation, and the human-approval gate.
What the corpus does today, and what the platform will do
Being precise about which is which matters here.
Today, the open corpus gives you the re-assessment model: the controls above, the evidence each requires, and the eight questions the new execution path raises. When a platform ships a capability, you have the checklist for what to re-assess and why your prior verdict no longer holds.
The Apeiris platform, in development, is the part that would detect the capability-graph change and surface it, mapping the new paths automatically and flagging which controls no longer cover them. The corpus is the model that platform evaluates against. Nothing on this site claims Apeiris watches your environment today, that is the boundary we hold to. See what exists today vs. what is being built.
The point
Correct controls are necessary. They are not sufficient, because they were assessed against an environment that can now do more than it could when it was approved. Nothing failed. The environment changed, and a capability graph that grows without a decision becomes an unmanaged risk. The first step is naming the change as a change worth re-assessing, against a model built for exactly that.
Read the underlying idea: correct controls, unassured outcomes →