Distribution Control: who can invoke an agent, under what authority, and how downstream actions are bounded

The question Distribution Control asks

Every other dimension in the Agent Certified framework, Trust and Safety, Context Integrity, Product Maturity, Governance, AI Integration, and the Autonomy Envelope, is in some way a question about the agent itself: what it does, how well it does it, what oversees it, and what it is permitted to do without a human present. Distribution Control asks a different kind of question. It asks who is allowed to make the agent act in the first place, under what proof of identity and authority, and if something goes wrong with that access, how large the resulting incident could become.

This distinction matters because an agent can score well on every behavioural dimension and still present serious risk if the access layer around it is weak. An agent with excellent guardrails, careful context handling, and a well specified autonomy envelope is still exposed if any developer with a copy of a shared API key can invoke it with no caller-specific limits, no record of who actually triggered a given action, and no segregation between the staging environment where experiments happen and the production environment where real customers are affected. The behavioural quality of the agent is irrelevant if the access controls around it cannot establish who did what, or cap how much damage any single access event can cause.

The five controls assessors evaluate

Authenticated invocation with no shared credentials. Every call that triggers the agent must be traceable to a specific, individually identifiable caller, whether that caller is a human user, a service, or another automated system. Shared API keys, generic service accounts used across multiple teams, and credentials embedded in code without individual attribution all fail this control. The test assessors apply is simple: given any single agent action in the log, can the organisation identify exactly which authenticated identity triggered it, without ambiguity, within minutes.

Role based authorisation tied to the organisation's identity provider. Authentication establishes who is calling. Authorisation establishes what that caller is permitted to ask the agent to do. This control requires that permissions are managed through the organisation's central identity provider, such as an enterprise single sign-on system, rather than through a separate, informally maintained access list specific to the agent. When access is managed centrally, offboarding an employee or contractor automatically revokes their ability to invoke the agent. When access is managed separately, it does not, and stale permissions accumulate silently.

Rate limits and spend caps per caller. Even a fully authenticated, correctly authorised caller should not have unbounded ability to invoke the agent. This control requires that each caller, whether human or automated, has an enforced ceiling on how frequently they can invoke the agent and, where the agent's actions have a financial dimension, how much spend a given caller can authorise within a defined period. The purpose is to bound the damage a single compromised or malfunctioning caller can do, independent of whether the compromise or malfunction was ever anticipated in the agent's own behavioural design.

Environment segregation. Development, staging, and production environments must be genuinely separated, with distinct credentials, distinct data, and no code path that allows an action initiated in a lower environment to reach production systems or production customer data. This control fails more often than organisations expect, particularly where an agent was built quickly and the same credentials, the same database connection strings, or the same tool integrations were reused across environments for convenience during early development and never separated out before the agent reached production.

Documented blast radius per tool. For every external system or API the agent is permitted to call, the organisation must document the worst-case scope of action available through that tool: the maximum number of records that could plausibly be affected in a single run, the maximum financial exposure, and whether the resulting action is reversible. This is the control organisations are least likely to have in place at first assessment, because it requires reasoning about failure scenarios rather than intended use, and because tool integrations are often added incrementally without anyone stepping back to ask what the absolute ceiling of harm looks like across the full set of tools combined.

Why the dimension is weighted at 12

The Agent Certified methodology weights Distribution Control at 12 out of 100, in the same band as AI Integration and below Trust and Safety at 18, Governance at 16, and Context Integrity and the Autonomy Envelope at 14 each. The rationale for this relative weighting is that Distribution Control failures tend, in isolation, to be contained. A single over-permissioned caller misusing an agent typically produces a bounded incident rather than a systemic one. What changes the risk calculus is scale: a shared credential or an absent blast radius assessment can turn what would have been a contained failure into one that reaches far more systems, far more customer records, or far more financial exposure than anyone anticipated, precisely because nobody had documented the ceiling in advance.

This is also why Distribution Control is scored separately from the Autonomy Envelope, even though the two dimensions are related. The Autonomy Envelope specifies what the agent is permitted to do once it is legitimately invoked. Distribution Control specifies who is permitted to invoke it and how far the consequences of that invocation can spread. An agent can have a perfectly specified autonomy envelope and still present serious risk if the access layer around it is weak, because the envelope only constrains behaviour after legitimate invocation has already occurred. Conflating the two dimensions would obscure exactly the kind of access-layer weakness that the five controls above are designed to surface.

The scoring rubric

A score of 1 to 3 indicates the organisation relies on shared or embedded credentials, has no role based authorisation separate from general system access, applies no meaningful rate limits or spend caps, does not segregate environments cleanly, and has no documented blast radius for any tool the agent can call. Most agents assessed for the first time fall in this range, typically because they were built quickly on shared service accounts during a prototyping phase and the access model was never revisited before the agent reached production use.

A score of 4 to 6 indicates authenticated invocation is in place and some role separation exists, but coverage is incomplete. Rate limits may exist for some callers but not all. Environment segregation may exist at the infrastructure level but share a data source or tool integration across environments in practice. Blast radius may be documented for the highest-risk tools but not systematically across the full tool set.

A score of 7 to 9 indicates full identity provider integration for every caller, enforced per-caller rate limits and spend caps across the full set of tools the agent can access, clean environment segregation with no shared credentials or data paths between environments, and a documented, current blast radius assessment for every tool. Organisations in this range have typically completed at least one internal access review specifically for the agent, separate from their general application security review process.

A score of 10 requires third-party verification that these controls hold under adversarial credential-abuse testing, meaning an independent assessor actively attempts to invoke the agent using stolen, shared, or improperly escalated credentials and confirms that the control layer detects and blocks the attempt. This is a materially higher bar than the 7 to 9 range, which relies on documentation and internal review rather than adversarial verification, and scores of 10 are correspondingly uncommon at initial assessment.

How Distribution Control interacts with the other dimensions

Distribution Control sits closest to Governance and to the Autonomy Envelope. Governance provides the institutional ownership, the named senior owner and the risk register entry, that should be driving the access review Distribution Control requires. Without governance ownership, access reviews tend not to happen on any regular cadence, and Distribution Control scores drift downward over time as new tools and integrations are added without a corresponding review. The Autonomy Envelope, as noted above, constrains what happens after legitimate invocation, while Distribution Control constrains who can legitimately invoke the agent at all. Operators working through both dimensions together typically find that the blast radius documentation required for Distribution Control and the resource threshold specification required for the Autonomy Envelope draw on much of the same underlying analysis, since both require enumerating what the agent's tools can actually do at the extreme.

For a full treatment of how all seven dimensions combine into a certification tier, see the seven dimensions article. For the closely related dimension covering permitted autonomous action, see the Autonomy Envelope deep dive.

Building toward a certifiable Distribution Control posture

Organisations starting from a low score typically follow a consistent sequence. The first step is a credential audit: identify every distinct way the agent can be invoked, and for each, determine whether the credential used is individually attributable or shared. Shared credentials are the single most common finding and the first thing to fix, because every other control in this dimension depends on invocation being individually attributable in the first place.

The second step is migrating authorisation into the organisation's central identity provider, so that access to the agent is managed through the same process, and revoked through the same offboarding workflow, as access to every other enterprise system. The third step is defining and enforcing rate limits and spend caps per caller, calibrated to what a legitimate caller actually needs rather than set high enough that the limit is never realistically approached. The fourth step is environment segregation, which for organisations that built an agent quickly often means retrofitting separate credentials and separate data connections for staging and production rather than designing them in from the start. The fifth and final step is the blast radius exercise: for every tool the agent can call, work through the worst case scenario deliberately, document it, and use that documentation to decide whether the tool's access level needs to be narrowed before certification.

A formal assessment under the Agent Certified methodology evaluates all five controls together and produces the certification artefact that demonstrates this posture to regulators, procurement counterparts, and insurance underwriters. For organisations preparing for AI liability coverage, a documented Distribution Control posture is increasingly part of what underwriters expect to see, since it is the layer that determines how contained an incident is likely to remain. More on how certification evidence feeds underwriting is available at agentinsured.eu.