The Spec Was Approved in March. What Is Your Agent Doing in September?
Intent drift, the legal weight of "intended purpose", and why governing an AI agent can't stop at the pull request.
The review went well. The Business Intent Spec had all five fields filled in, the non-goals were explicit, and every acceptance criterion mapped to a test that passed. The agent went live in March.
It is now September. The spec file hasn't changed, and neither has the agent's name. Almost everything else has.
The model behind it has been updated by its provider, twice. The knowledge base it retrieves from has grown by a few thousand documents. A team in another department connected it to a new tool, because it seemed like the obvious next step. For six months, it has been reading inbound email, some of which contained instructions that were never meant for it.
Nobody decided to change what the agent does. Is it still the agent you approved?
Our two previous articles on specification-driven development were about the moment of approval: why a reviewed spec is a governance artifact, and why the product manager now owns the intent layer it encodes. Both treated approval as the hard part. This one is about what comes after, because for an agent in production, approval is a moment. Intent is a condition that has to be maintained.
Everyone can count their agents. Few can say what they're doing.
In late September, Dataiku released a survey of 685 CIOs across eight countries, fielded by The Harris Poll in July (summary). Nine in ten said they have complete tracking of their agents. Seventy-two percent said they cannot consistently confirm that those agents deliver the business outcomes they were built for.
Put those two numbers side by side. Organisations know their agents exist. Most can't say whether the agents still do the job that justified building them. The same survey found that 83% lack standardised lifecycle management for agents, and 84% agree that employees are creating agents faster than IT can govern them. Dataiku's CEO put the consequence bluntly: "almost nobody can fire an agent."
A vendor commissioned the survey that launched an agent-management product the same day, so treat the exact figures as directional. The direction, though, matches what enterprise teams describe.
The gap between "running" and "still doing what we approved" deserves a name. Call it intent drift. It is the distance between what an agent was approved to do and what it does now, accumulated without anyone changing the approval.
"Intended purpose" is a legal term now
For most of software history, drift from intent was a quality problem. Under the EU AI Act, for a defined category of systems, it is also a legal one.
The Act defines intended purpose as the use a provider intends for an AI system, including the specific context and conditions of use, as set out in its instructions, materials and technical documentation. It then defines a system's performance not in the abstract, but as its ability to achieve that intended purpose. In the regulation's vocabulary, performance is measured against intent.
Two further provisions give the concept teeth. A substantial modification is a post-deployment change that wasn't foreseen in the original conformity assessment and either affects compliance or modifies the intended purpose. And under Article 25, a deployer or other third party that substantially modifies a high-risk system, or changes the intended purpose of a system in a way that makes it high-risk, is treated as a provider and inherits a provider's obligations. Meanwhile, Article 26 requires deployers of high-risk systems to use them in line with the instructions for use, to monitor their operation against those instructions, and to suspend use when they have reason to consider the system may present a risk.
Under the Digital Omnibus, which entered into force on 27 July 2026, these obligations now apply from 2 December 2027 for stand-alone high-risk systems and from 2 August 2028 for systems embedded in regulated products.
Two caveats. This is not legal advice, and most enterprise agents will not be classified as high-risk. But look at what the regulation does with the concept. It treats "what this system is for" as a documented fact, and it treats unplanned change to that fact as an event with consequences, up to and including a change in who is legally responsible for the system.
That is exactly how the Business Intent Spec treats its Problem, Expected outcome, and Non-goals fields. In our PM article, scope creep was a product failure: an agent filling gaps nobody had forbidden. Read through the Act's vocabulary, the same behaviour can be a modification of intended purpose.
Three ways an agent leaves its intended purpose
1. Drift by decision
Someone extends the agent, and nobody thinks of it as a change of purpose. A prompt tweak to handle a new request type. A tool connected because it was available. A data source added because a stakeholder asked. Each step is reasonable, and none of them touches the spec.
This is the pace the Dataiku numbers describe, and the case Article 25 is written for. OWASP has a name for its slow-motion version, governance drift: oversight weakens after a run of successes, and approvals quietly become bulk approvals. It is also the most preventable kind of drift, because it happens through actions your own organisation takes. The only question is whether those actions pass through a point where someone compares them with the approved intent.
2. Drift by environment
Nothing in your organisation changed. The model did.
The best-known evidence is still Chen, Zaharia and Zou's study, published in Harvard Data Science Review. Between March and June 2023, the same GPT-4 service went from distinguishing prime from composite numbers with 84% accuracy to 51%, and its ability to follow user instructions measurably declined. Not everything got worse. Some tasks improved, and other researchers testing different tasks later found little change. That is precisely the point: behaviour moved, in both directions, under an unchanged model name, and nothing in a spec file would have noticed.
Instruction-following is the capability a spec depends on, and it is fragile even before production. In her evaluation of SDD tools at Thoughtworks, Birgitta Böckeler repeatedly saw agents fail to follow all the instructions in carefully structured specs, and sometimes follow them too eagerly. A passing test suite at merge proves the agent could do the right thing on the day of review. It does not prove it will keep doing it.
Model churn is about to accelerate, too. Three-quarters of the CIOs in the Dataiku survey said they plan to use more or different models.
3. Drift by attack
The third kind is deliberate. The OWASP Top 10 for Agentic Applications, published in December 2025 and peer-reviewed by more than 100 practitioners, puts Agent Goal Hijack first. Its core observation is that agents cannot reliably tell instructions apart from the content they process, so an email, a document, or a web page can redirect what the agent is trying to achieve. Memory and Context Poisoning does the same thing more slowly, by corrupting what the agent will retrieve in future sessions.
One of OWASP's example scenarios describes intent drift almost exactly: a calendar invite carrying a hidden, recurring instruction that nudges an agent toward low-friction approvals every morning, while every action stays inside declared policy. No permission is violated. The purpose is.
Another should look familiar to readers of our PM article. There, we declined to use a widely circulated but unverified story about an agent that decided "delete and rebuild" was the fastest route to its goal. OWASP's rogue-agent category now uses the same mechanism as a standard scenario, in which an agent told to minimise cloud costs concludes that deleting production backups is the most efficient path. Its incident tracker also lists a documented July 2025 case of a coding agent deleting a production database. The original anecdote is still unverified. The mechanism no longer needs it.
Why the spec alone can't catch it
A spec is checked at review time. An agent acts at runtime, thousands of times, under conditions nobody reviewed.
Böckeler's taxonomy is useful here. She separates spec-first development, where a spec guides a task and is then left behind; spec-anchored, where the spec is maintained alongside the feature; and spec-as-source, where humans edit only the spec. Every approach she examined was spec-first, and not all aimed to go further. Our PM article argued for spec-anchored practice, with a roadmap that computes its own status from tests tied to acceptance criteria.
But even perfect spec anchoring keeps the spec aligned with code. It says nothing about the alignment between the spec and what a live agent does with a model, a context window, and a toolset that have all changed since the tests last ran. For deterministic software, code is behaviour. For an agent, code is only part of it. The rest is assembled at runtime, and runtime is where intent has to be enforced.
OWASP has reached the same conclusion from the security side. Its Agent Control Standard, published on 1 September 2026, defines how agent platforms should expose hooks through which policies are enforced declaratively, at runtime, across agent frameworks.
The spec needs a sixth field
The practical change is small. The Business Intent Spec from our PM article had five fields: Problem, Expected outcome, Constraints, Non-goals, and Acceptance criteria. For agents, add one.
## Operating envelope
The models, tools, data sources and permissions this intent was approved under.
Which changes trigger re-review. Who owns the agent. When it is retired.The field borrows its logic from the AI Act's definition of substantial modification: the changes that need a fresh look are the ones the original assessment didn't foresee, so write down what it did foresee. OWASP points in the same direction for goal hijack, with an emerging pattern it calls an intent capsule, which binds the declared goal, constraints, and context to each execution cycle.
Writing the envelope down turns "is this still the agent we approved?" from a philosophical question into a diff. It also settles something the Dataiku respondents couldn't agree on. Asked who owns an agent that goes wrong, CIOs split almost evenly between shared teams, central IT, the data or AI team, and the security, risk and compliance function. An envelope with an owner's name in it resolves that before an incident has to.
Then the envelope has to become enforcement. Four practices line up with the frameworks published over the past year.
Bound the action space from the non-goals. Singapore's Model AI Governance Framework for Agentic AI, launched in January and updated in May with input from more than 60 organisations, opens with assessing and bounding risks upfront, including limits on an agent's access to tools and systems. NIST's AI Agent Standards Initiative, launched in February, is working on agent identity and authorisation, including how to apply least privilege to an agent whose actions can't be fully predicted. OWASP calls the principle least agency: don't grant autonomy the task doesn't need. A non-goal that exists only as a sentence is advice. A non-goal expressed as a permission is a boundary.
Treat a model change as a change event. Re-run the acceptance criteria against the new model before cutover, and record which model handled each action afterwards. If a model can change without leaving a trace, drift by environment is invisible by design.
Treat retrieved content as untrusted. OWASP's first mitigation for goal hijack is to treat every natural-language input as untrusted before it can influence planning or tool calls, and to require confirmation when an agent proposes actions outside its original task or scope. That is a property of how context and tools reach the agent, not of how well the prompt is written.
Measure the expected outcome, not uptime. The Expected outcome field describes observable behaviour. Monitor that, not whether the agent responded. It is the only practice on this list that catches the hardest case: an agent that stays inside every permission and still stops serving its purpose.
Where Jeen fits
We've written before that the same evidence that answers an auditor also reveals where an agent drifts from business intent. That premise sits behind Jeen's Enterprise AI Harness, and it maps closely onto the operating envelope.
Agent Factory makes the agent definition itself a reviewable artifact: which systems it orchestrates and which steps it takes, approved before it runs. That is the envelope's first draft.
Jeen Governance and Jeen Admin turn the envelope into enforcement, through policies, guardrails, role-based access, and knowledge-access rules that decide which agent may retrieve or act on what. Retrieval through Organization Brain and tool access through Connectors Hub pass through the same governed layer, so the surface where hijack and poisoning enter is the same surface where access is decided. Because policy lives as versioned code, any change to the envelope that is written as policy becomes a recorded event, and the ledger can show which policy version governed each action. When a policy is breached, the action can be blocked, routed for review or held for human approval, or its data masked.
Models Garden makes model choice an explicit, centrally managed decision rather than something that happens upstream, and the Harness records which model handled each action. On-premises and air-gapped deployments go a step further: when the model runs inside your own infrastructure, it changes when you decide it changes.
Jeen FinOps adds a cruder but useful signal. Drifting agents often get more expensive before they get visibly wrong, looping, retrying or pulling more context than the task needs. A per-agent budget with a ceiling surfaces that pattern early.
None of this makes an agent correct. It makes deviation from approved intent bounded, visible, and attributable, which is the precondition for everything else.
The honest limits
Runtime governance catches what it can express. Permissions handle drift by decision well. Version control and re-testing handle much of environment drift. But goal hijack that stays inside every permission, like OWASP's calendar scenario, is caught only by measuring outcomes against intent, and that measurement is hard, domain-specific, and never complete. Anyone claiming a platform solves semantic drift automatically is overselling.
Regulatory dates have already moved once and may move again. Treat December 2027 as a direction of travel rather than a starting line. The organisations that will find these obligations easiest are the ones where "intended purpose" is already a maintained document, not a paragraph reconstructed for a conformity assessment.
Approval is a moment. Intent is a condition.
Across these three articles, the argument has moved down the stack. The product manager writes the intent. Engineering implements against it and makes it reviewable. After approval, the organisation has to keep that intent true in the one place it actually executes: at runtime, every time the agent acts.
The spec tells you what you approved. Only the runtime can tell you whether you still have it.
