Last week I left you with three checks. The third one was “name the owner”: whose name is on the policy your agents run under?
And well... I ran that third one in a customer room recently. Who were there? The CIO, the cloud lead, a security engineer and two engineering managers. The answers came fast.
“Security, I think.”
“Well, the gateway is ours, so the tool list is platform.”
“The repo rules are ours, we wrote the AGENTS.md.”
Three answers, all true... and a quietness that arises when people notice that the answer to “who owns the policy” was everyone... which in an org chart means nobody.
So I did what I do when a room goes quiet... think, discuss and read from others’ experience. Not the frameworks... the engineering blogs. What did Dropbox, Uber, Spotify, Atlassian and Datadog actually write, in 2026, about who decides what their agents may do?
In essence, none of them has A policy owner. All of them have four.
Issue 1 named the trap: one program, not three.
Issue 2 named the destination: AI-native, not AI-ready.
Issue 3 put three bodies on the table that have to move together.
Issue 5 found Herbie: your bottleneck doesn’t burn tokens.
Issue 7 taught one repo and moved a fleet.
Issue 9 asked who reviews the reviewers.
Issue 10 found the software factory was always there.
Issue 11 moved the gate before execution and gave the humans the policy to write.
No kit this week: the argument, five posts you can read yourself, and the standing ask: if this lands, forward it to whoever was about to hire a “Head of AI Governance”.
Dropbox gave the decision back
The story that made me sit up is not the one with the biggest numbers. It is the one where decision rights moved, and moved in the direction I didn’t expect (towards the team, not the centre).
Dropbox runs its coding agents on an internal platform called Nova. Mike White and Kevin Altschuler wrote it up in May. Before Nova they had an in-house migration tool that generated parallel agent jobs from prompt templates, ran the verification commands and published branches. Thousands of migrations went through it. It worked... until it didn’t...
And what seems obvious in hindsight was that they had no simple way to review the agents’ output and then “continue” it with their input... so whenever something broke/failed, there was no practical way to recover/checkpoint the work.
And then the sentence I underlined twice: “highly repeatable migration work was often better handled directly by migration owners, who could launch and manage dozens of agents with the same runbook rather than coordinating delegated work across teams.”
Read that again with the org chart in mind and remember Issue 7 with the airline. The central team did not take more control. They gave the runbook back to the person who owns the migration, and kept for themselves the things a migration owner should never have to think about: isolated execution, hermetic tests, the CI loop and one rule they state in plain words: “We chose to keep publication outside the agent and limit each session to a single branch.”
So who owns the policy at Dropbox? The platform owns what the agent structurally cannot do (publish, branch, skip CI). The migration owner owns what the agent will do today (the prompt, the runbook and, they say, soon the rollout). Two owners, two different kinds of decision and no committee between them.
And that split is not a Dropbox quirk... let me show you.
Four rights, not one job
Dropbox is one of the five posts I read. The other four (Uber, Spotify, Atlassian and Datadog, all linked below) tell the same story from a different desk: put them side by side and the same four decisions keep landing in the same four places.
1. The invariants sit with security. Uber’s post on agent identity (six authors from Engineering Security and AI Security, May 2026) is the clearest. Every agent gets an identity. Every call into Uber’s systems goes through an MCP Gateway that is, in their words, “a policy enforcement point for MCP tool invocations”. And it works by defining policies based on internal risk classification... if it’s a high risk, it’s MANDATED. See? Not proposed to a working group. Security decides which systems are high risk and what an agent must present to touch them. What Uber’s post does not say is that security decides what any agent is for. That is someone else’s right.
2. The mechanism sits with platform. Spotify’s Niklas Gustavsson described it in June: Backstage, Soundcheck, “golden state” (the recommended stack per component type) and lint. They claim that, combined with static analysis and linting, standards become active guardrails. The platform team did not write a policy document for agents. It pointed the guardrails it already had at a new kind of contributor. Dropbox’s Nova is the same move: the platform owns execution, isolation, validation and the CI trigger. Datadog’s version is a guild (”Frontend Augmented by AI”) that sets golden paths for over 50 teams. Platform owns how checking happens. Not what is allowed and not what the agent is doing.
3. Local intent sits with the team that owns the code. Atlassian’s Jira team encoded its own cleanup knowledge into agent skills, then hit the wall every large org hits. You cannot have “one-size-fits-all” solutions in a company with 1000’s of repos owned by 100’s of teams... so Atlassian’s answer is repository-specific skills, with repo owners asked to write the cleanup procedure for their own repo. Datadog goes in the same direction by using the control with the smallest scope that still gives the desired output. So they go developer-local first, then the package, then the repo root. The team decides the task, the instructions and whether a piece of work is worth delegating at all.
4. Exceptions sit with a named human. Not a role, but A person. Atlassian keeps it simple by having engineers validate the change before it is merged. Dropbox kept publication out of the agent’s hands entirely. And if you operate in Europe this one is not optional: the AI Act requires that high-risk systems have human oversight by people with “the necessary competence, training and authority”, who can decide not to use the output, override it or stop the system. The Act does not say which team those people sit in, just that they must exist and be able to act.
Now back to the tease from last week, because I promised three answers.
Who owns the policy? Put the five together and you get 4 people... the trick is that each owns a different verb: security mandates, platform enforces, the team instructs and a named human overrides.
What can they decide without asking anyone? Security can add a system to the high-risk list. Platform can change how a check runs. The team can change what its own agent is told and what it works on. The human can say no. Each of those is a decision nobody else gets to block and each one is useless without the other three.
Where do they sit? Security is security. Platform is your platform team, the same one that owns the paved road, not a new one. The team is stream-aligned, in Team Topologies terms. The guild at Datadog is the enabling team: it sets the path, measures it, and hands it over. And the human with the override sits wherever the blast radius is... which is why it has to be a name and not a box.
The standards will not tell you, and that is good news
So Thiago, should we read NIST or ISO’s standards to know what to do? Well... I did, but there are dozens out there... and frankly, they are deliberately silent on exactly this question.
NIST’s 2026 agent work (the identity and authority concept paper, the Agent Standards Initiative) is about identification, authorization and audit. Technical as NIST has always been. It assigns no owner. ISO/IEC 42001 says an organisation must “define responsibilities for AI use” and stops there, on purpose, because it is a management-system standard and not an org chart. And the AI Act (Article 26) explicitly preserves the deployer’s freedom to organise its own resources.
So the law tells you the override must exist and the person must have authority. The standards tell you responsibilities must be assigned. Neither tells you to whom... this is not a gap, just a way to tell you it’s your decision.
The consultancies, of course, are happy to fill the silence. BCG’s Enterprise AI Control Plane (August 2026, consultancy research) argues for “a designated owner with the mandate and authority to enforce standards across platforms”, with Enterprise Architecture leading it, and separates a “control layer” from a “build layer”. Team Topologies argues the other way (their own consultancy’s position) with “the stewardship boundary around the value flow remains the remit of the human team”.
But look at what each one is actually asking to own. BCG’s “control layer” is identity, the agent registry, runtime enforcement and golden paths: the invariants and the mechanism, rights 1 and 2. Team Topologies’ “stewardship” is what the team is trying to achieve and what it tells the agent to do: the intent and the override, rights 3 and 4. Neither is claiming the other’s half. They only sound opposed because both call their half “governance”... and the moment you name four rights instead of one, the fight disappears.
What auto-merges is the real fight
If the four rights were the whole story this would be a tidy post. They are not, because two of the five companies disagree on the one decision that matters most day to day: what ships without a human looking at it.
Spotify has a fleet system with more than 2.5 million automated maintenance PRs the vast majority auto-merged, no human in the loop. Their most recent Java migration across the backend took three days. And with agents in the mix they now have 76% more PRs to review, so their post ends with something I hear over and over and over and over again: they auto-merge what is safe, focus human review where it matters most, and are rethinking how they plan “as the bottleneck moves from coding to decision-making” (their words).
Atlassian’s story came out in the same month with the same type of work (flaky tests, cleanup chores), but with a distinct decision when compared to Spotify. First, the agent does the repetitive context gathering with investigation, diagnosis and a proposed fix. Then engineers validate the change before it is merged. Every single change... They report about one engineering week saved per month and up to 80% fewer engineering hours on flaky tests specifically...
Can both be right? I think so, and I think Dropbox’s story has the reasoning. Dropbox validates a flaky-test fix by running the test 100+ times in CI before it lands, and kept the CI trigger outside the agent. Why? Otherwise you get changes validated against the wrong tests. Spotify’s fleet changes are deterministic scripts against a standardised stack, with the same lint on every component, while Atlassian’s run across 1000+ repos with different conventions.
So the variable is not how mature your AI is. It is whether the change has a deterministic check and a bounded blast radius. Where both hold, auto-merge is a policy decision that platform (right 2) can make and security (right 1) can veto. Where either fails, the named human is not a transition phase. The human is the design... And here we are in the same conclusion as last week, one floor up.
And a geek aside for the people who write AGENTS.md files (hello, Context Engineering, we meet again): Datadog measured what happens when you remove the root-level one: 13% faster runs, 16% fewer input tokens and 10% lower spend. And they say this happens with a roughly 7% decrease in output consistency, which they plan to recover by moving the instructions into more finely scoped controls, including skills, hooks, lint rules, tests.
But notice what it is: an economic argument for Intent (right 3). A global instruction file costs the agent the way a global standards manual costs a developer... then, let’s push intent down to where it is used.
Policy on paper is not policy at runtime
That is three companies pushing intent down. I wanted to know what the other few thousand do, and while thinking on how to gather data from different companies about Agentic AI policies, I came across an interesting survey. Enterprise Management Associates asked 202 CIOs, CTOs, CISOs and IT directors at companies with more than 1,000 employees about their agents (August 2026, commissioned by Cequence Security, a vendor with a product to sell, methodology in the PDF). 94% were confident their agents do not have more access than they need. 33% actually provision least-privilege access. 34% check an agent’s authorization at the moment it tries to act.
I do not trust a sponsored survey to three significant figures. I do recognize it from a few of my customers, because it is the shape from Issue 11: a policy that exists as a document versus a policy that is checked before the first tool call. If I accept the numbers from the research it would be like 9 in 10 leaders are sure the policy holds, but only 3 in 10 have the check that would prove it.
And now you can see why “who owns the policy” gets the everyone-therefore-nobody answer, right? If the policy is a document, everyone can own a paragraph. If the policy is a check that runs, somebody has to own the check (platform), somebody the rule it enforces (security), somebody the instruction it enforces it on (the team) and somebody the moment it says no (a human). The four rights are not a governance model I am proposing. They are what falls out of moving the policy from paper to runtime.
The three-body reading
You knew this was coming.
The team body is this whole issue. Four rights is an org-design decision. No model release makes it, no verifier makes it, no framework makes it for you. It is the part the “buy the guardrail” plan skips, and it is the part the room went quiet on.
The architecture body is the gateway and the contracts. Uber’s MCP Gateway is right 1 made physical. Spotify’s lint-as-guardrail is right 2 made physical. Neither exists in a company whose tools have docstrings instead of contracts (Issue 11’s check 2, still open on most whiteboards I see).
The capability body is the verifier, the thing from last week. It is the least interesting of the three this week, which is the point: a verifier in a company that has not decided who mandates, who enforces, who instructs and who overrides is a very fast way to enforce nobody’s policy.
And the sequencing trap, one more time, because it has a new costume. It is called “Head of AI Governance”. Hire that person first, with the four rights undivided, and you have built a committee with a job title. They will write the document. Nine in ten are already sure it holds.
And this is the second exercise in the lab I run with customers, right after the 5-line policy from last week: for one real workflow, four names on one sheet. Who mandates, who enforces, who instructs, who overrides. The blanks are the diagnostic, and so far the blank is almost never “security” :-]
Where it does not reach yet
Every practitioner story above is a company writing about itself on its own blog. Uber, Atlassian, Dropbox and Spotify have independent coverage that matches. Datadog’s numbers are Datadog’s alone. That is the weight of it: five honest accounts, zero audits.
AFAIK, there is no peer-reviewed study that tests one org design for agent policy against another... nobody has measured how long it takes a company to approve a new agent capability, or what share of the rules are written centrally versus in the repo. The surveys collapse all four rights into one question called “governance”, which is why they cannot tell you anything about the split.
You can be sassy and claim that all these companies are software companies, so heavily regulated banks/airline/telco/public sector will have a different shape. I have seen the same pattern in regulated rooms. The difference is that those companies do not write blog posts, and I do not put clients in newsletters.
And the Dropbox story is about migrations, repeatable work with a runbook. Whether “give the runbook back to the owner” holds for work that has no runbook is exactly the Spotify-versus-Atlassian question, and it is open.
Run it on yourself
More checks for you to self-assess... now one floor up from last week’s.
Four names, one workflow. Take the agent workflow you wrote the 5-line policy for. Write the four names: who can add a system to the high-risk list, who can change how the check runs, who can change what the agent is told, who can say no at the moment it acts. A blank is a finding, but I think 2 names in one box is a bigger one.
Find one thing that auto-merges. If nothing does, ask why not: is there a change class with a deterministic check and a small blast radius or is “human reviews everything” a policy nobody decided? If something does, find who decided, and whether security (right 1) knows.
Find where one rule lives. Pick one instruction your agents follow. Is it in a root file every agent reads on every run, or in the smallest scope that needs it? If it is at the root and applies to one team, you are paying Datadog’s 16% in tokens for the privilege of a committee owning it.
Run the three and you know whether your policy has four owners or one document.
The whole thing, in one line
Stop looking for the owner of the policy. Split it into the four decisions it always was, and put a name on each.
Coming up
Next week I want to leave the org chart and go back to something with a terminal in it. Hands dirty, numbers on the table. More soon. :-]
Sources
Mike White, Kevin Altschuler, “Introducing Nova, our internal platform for coding agents”, Dropbox.Tech, 21 May 2026. https://dropbox.tech/machine-learning/introducing-nova-our-internal-platform-for-coding-agents
Matt Mathew, Prasad Borole, Meng Huang, Sergey Burykin, Gaurav Goel, Bayard Walsh, “Solving the Identity Crisis for AI Agents”, Uber Engineering Blog, 21 May 2026. https://www.uber.com/us/en/blog/solving-the-agent-identity-crisis/
Spotify Engineering, “Coding Is No Longer the Constraint: Scaling Developer Experience to Teams and Agents at Spotify”, 3 June 2026, a write-up of Niklas Gustavsson’s (Chief Architect and VP of Engineering) Code with Claude 2026 talk. https://engineering.atspotify.com/2026/6/code-with-claude-coding-is-no-longer-the-constraint
Arnaud Moret, WaiYee Loo, “How We Cut up to 80% of Engineering ‘Chores’ Using AI Agents in Jira”, Inside Atlassian, 1 June 2026 (the 80% figure applies to flaky-test hours). https://www.atlassian.com/blog/development/ai-agents-jira-engineering-maintenance
Addie Beach, Rui Martins Lacerda, “How we built data-driven AI Golden Paths at Datadog”, Datadog, The Monitor, 9 September 2026 (the A/B figures are Datadog’s own, unreplicated). https://www.datadoghq.com/blog/ai-development-golden-paths/
Regulation (EU) 2024/1689 (the AI Act), consolidated text of 27 July 2026, EUR-Lex. https://eur-lex.europa.eu/eli/reg/2024/1689/2026-07-27/eng
NIST, “New Concept Paper: Identity and Authority for Software Agents”, 5 February 2026 (a concept paper, evolving). https://www.nist.gov/news-events/news/2026/02/new-concept-paper-identity-and-authority-software-agents
ISO, “ISO/IEC 42001 explained: what it is”, September 2026. https://www.iso.org/home/insights-news/resources/iso-42001-explained-what-it-is.html
Shaheer Rizvi, Zeeshan Shah, Sarvesh Singh, Nicolas Tanaka, Francois D’Agostini, Jazz Tobaccowalla, “Enterprise AI Control Plane: The CIO’s Guide to Governing and Accelerating AI Agents”, Boston Consulting Group, 14 August 2026. https://www.bcg.com/publications/2026/how-cios-govern-ai-agents-at-scale
Team Topologies, “Executive Report: Team Topologies as The Organizational Foundation for AI ROI”, 12 August 2026, via the AI Workforce Readiness page. https://teamtopologies.com/ai-workforce-readiness
Enterprise Management Associates for Cequence Security, “Agents Without Guardrails: The Agentic AI Governance Gap in the Enterprise”, 31 August 2026, n=202 (vendor-commissioned survey. Press release https://www.cequence.ai/news/ai-agent-governance-research/ and report PDF https://www.cequence.ai/wp-content/uploads/2026/08/EMA-Research-Report-Agents-Without-Guardrails.pdf
Further reading (not cited in the body):
InfoQ’s independent write-ups of the Uber (17 June 2026, https://www.infoq.com/news/2026/06/ai-agent-identity-uber-auth0/) and Dropbox (June 2026, https://www.infoq.com/news/2026/06/dropbox-nova-ai-coding-agents/) posts, which is how I checked that I was not reading a press release as engineering.