Agent Control Points
Three essays separate three questions that the market keeps collapsing into agent identity. Four companions then ask whether the resulting seams can ship before product defaults harden, what an agent does when it hits one mid-task, and which state must survive the suppliers. A capstone assembles the whole argument into six rules, one trace, and the replacement tests.
Distribution determines the default. Standard seams determine whether the default can be challenged.
One confusion runs through all three contests. Enterprise computing keeps mistaking where evidence originates for where authority belongs. The runtime sees the instance first. The harness sees the work first. The credential provider sits in the access path first. Those positions create strong defaults, not natural rights to own every record and decision above or below them.
The distinctions are the argument. Evidence is not enterprise identity. Identity is not approved work. A credential is not a task. And no upstream artifact is permission for a resource to act. Whether products preserve those distinctions is being decided now, in working groups and early deployments.
The first question a strategist will ask is why one vendor cannot simply own all of this. Inside one vendor’s walls, it can. Microsoft can own all three control points inside Microsoft, and OpenAI inside OpenAI. The moment an enterprise runs five runtimes, thirty SaaS applications, internal software, and external partners, the records those control points govern stop being provider records and become enterprise records, because they have to survive every change of runtime, model, and application underneath them. And the heterogeneity is increasingly chosen rather than suffered, because enterprises multi-source inference deliberately and route work across model suppliers by cost and capability. Heterogeneity moves ownership. The single-vendor estate where it does not is the honest counter-case each essay carries.
The series uses one map throughout, and its questions are the ones any investigation of an agent’s action has to answer, in order:
| Control point | The question it answers | Governing interface, record, or decision | Reading |
|---|---|---|---|
| Provider seam | How does the agent acquire and present a credential? | Mechanism-hiding interface, key custody, and credential policy | Essay 1 |
| Identity binding | Whose Agent is this, and which approved deployment is running? | Enterprise Agent and Agent Deployment records bound to runtime evidence | Essay 2 |
| Approved work | Why does authority exist, and when does it end? | Approved-task record with its own owner, bounds, and lifecycle | Essay 3 |
| Resource decision | May this concrete action proceed now? | Current resource policy and local authorization decision | Outside the three upstream contests |
That order is the investigator’s, working from the credential in the logs back to the reason the work existed. It is not a call stack. The four are different kinds of things, an interface, two records, and a runtime decision, and the forward trace below visits them in a different sequence than an investigation does.
The first three are the control points this series contests because products can compete to own their interfaces and durable state. Control has a specific meaning here, and it accumulates rather than switching on:
Control accumulates through four powers: setting the default interface, holding the durable records and audit history, deciding which competing artifacts are admitted, and making replacement expensive. A vendor that holds all four owns the control point. Most hold one or two.
The powers also split across parties. A standard can set the default interface while a vendor holds the records and a third party projects the credential, which is exactly the division the Cross App Access companion documents in production.
| Control point | What its owner controls |
|---|---|
| Provider seam | Mechanism selection, key custody, downgrade policy, and the telemetry of every access path |
| Identity binding | The Agent inventory, deployment eligibility, lifecycle state, and incident joins |
| Approved work | The approval surface, authority derivation, termination, and task-level audit |
| Resource decision | Actual acceptance and enforcement, which no upstream owner can command |
The fourth is a control point too, and a heavily contested one, with resource vendors, policy engines, and gateways competing over it. This series leaves it outside its scope for a structural reason rather than a competitive one. Resource authorization is the non-delegable final decision. No upstream identity, credential, or approved-task record can command a resource to act, and the three portable upstream surfaces exist to deliver assurance to that decision, which is why the series’ assurance rule stays conjunctive:
Permit = valid runtime evidence AND eligible Agent and Agent Deployment AND live approved task AND valid credential AND resource policy permits.
This is a decomposition of assurance, not a requirement that every resource synchronously fetch five systems on every call. Evidence can be verified upstream, decisions can be projected into short-lived credentials, and higher-consequence actions can demand fresher checks. The point is that no predicate silently substitutes for another.
Run forward, the decomposition is one trace. The runtime produces instance evidence. The binding layer resolves it to an Agent and approved Agent Deployment. The approved-task record establishes purpose, bounds, owner, and expiry. An issuer projects the eligible subset into a short-lived credential. The provider seam acquires and presents it. The resource evaluates the concrete action under current policy. Audit joins the action back to all three records. Run backward from a termination, the same trace shows what stops. A non-active task ends new derivation immediately, outstanding credentials age out at their published freshness bound, and consequential actions that require current state fail closed at the boundary.
Drawn once, for every essay in the set to reference:
instance evidence] --> BL[Binding layer
Agent + approved Deployment] BL --> IS[Issuer
eligible identity projection] TR[Approved-task record
purpose, bounds, owner, lifecycle] --> IS PS[Provider seam
credential interface + custody] -->|requests for audience| IS IS -->|short-lived credential| PS PS -->|presents| RD{Resource decision
current policy} RD -->|allow| EF[Consequential effect] RD -->|deny| DN[Terminal or
requestable denial] DN -.->|approved remediation
causes re-evaluation| RD EF --> AU[Evidence plane
joins action to records] RD --> AU AU -.-> BL AU -.-> TR
One actor in that trace deserves an explicit non-entry. The issuer decides which binding evidence it accepts, which task state it consults, and what claims, audience, and lifetime the projected credential carries, so an OAuth reader will reasonably ask why issuance is not a fourth upstream contest. The answer is that its role is projection. A well-behaved issuer compiles identity eligibility and approved work into a resource-specific credential without becoming authoritative for either record, and its practical power comes from downstream acceptance rather than from state it owns. It is a chokepoint, not a system of record. An issuer that starts holding those records instead of reading them has not created a new control point. It has bundled the second and third.
One adjacent contest stays off the map deliberately. The intelligence layer, the memory, context, and model-routing state enterprises are building to keep inference suppliers replaceable, raises the same ownership question one layer over. It is durable enterprise state, but it is not identity or authority, so it earns a companion of its own rather than a fourth row here.
Read the three essays in order if you are choosing agent platforms, building them, or designing the standards that keep their boundaries contestable. Then use the companions as the delivery test, the worked cases, and the boundary of the state that must survive.
Essay 1: Kerberos Won Because Nobody Had to Implement It
Kerberos did not win the enterprise on protocol merit. It won because SSPI hid the mechanism, the LSA owned credential lifecycle, Active Directory shipped enrollment and issuance by default, and SPNEGO made rollout incremental. Mapping that stack onto agents names the first control point, the provider seam through which a harness or gateway acquires and presents credentials without exposing the mechanism to agent logic. Fragments exist, from MCP clients to SPIFFE to vendor brokers, and no general seam composes them yet.
Essay 2: The Runtime Mints the Identity. That Does Not Make It the Authority.
The platform that runs an agent produces the first trustworthy evidence about it, and convenience has a way of becoming architecture. But runtime proof and enterprise binding are separate jobs. The binding layer turns evidence from any supported runtime into an enterprise-governed Agent and Agent Deployment, and it is contested by bundled, layered, and provider binding plays. It is a real control plane only if the enterprise records survive changing runtimes, and even a won binding layer answers whose agent is running, not whether its work is still approved. It ends with five questions a buyer can run.
Essay 3: Agent Authority Has No General System of Record
Agent harnesses already ask humans to approve actions, identity systems already issue reusable grants, and enterprises already record change approvals. None is a general, machine-checkable system of record for approved work. Task approval, reusable consent, and action step-up are three different grains, the transport primitives to carry a real record already exist, and the shared task semantics do not. Whoever mints the durable record of the approved task owns the third control point. It ends with six questions a buyer can run.
Companions: The Clock, a Worked Case, a Recovery Pattern, and the Memory
The MCP Lesson adds the missing clock. A seam can be well designed and still arrive too late. Its first useful deployment needs an adoption wedge: a small coordination radius, immediate utility, low exposed implementation cost, and a path from one controlled loop to multilateral interoperability.
Cross App Access Shows How the Layered Play Ships applies that test to a live case. MCP’s stable Enterprise-Managed Authorization extension, a Claude and Okta beta, and a wider early-adopter coalition show how vendors can pre-assemble an irreducibly multi-party loop. The result is a real credential-projection foothold, not yet the portable Agent binding or approved-work record defined by Essays 2 and 3.
A Blocked Agent Is a Captive Client works the pattern grain under the market analysis. A mid-task egress block is a requestable denial and the egress proxy is an enforcement point, and RFC 8908’s captive-portal state machine already defines the recovery loop a headless agent needs: discover captivity, learn the remediation endpoint, wait, retry after policy changes. It is the series’ enforcement honesty carried down to the wire.
The Company’s Memory Must Be an Enterprise Record carries the ownership question into the intelligence layer. It separates working context, task state, evidence, candidate memory, and canonical institutional knowledge, and argues the last earns the name enterprise record only under governed meaning, provenance, lifecycle, and portability. Reads are exposure decisions, writes change future behavior, and the approved-task record bounds both without becoming the memory itself.
The Capstone
The Enterprise Agent Control Stack assembles the set. Six rules preserve the boundaries among evidence, records, projections, and decisions, a forward-and-reverse trace tests execution and termination, and five replacement tests show which state must survive each supplier. Read it first for the map, or last for the architecture review.
The Buyer’s Floor
The tests in Essays 2 and 3 compress to a floor procurement can demand of any agent platform, and the MCP companion argues procurement is exactly the lever that finishes a multilateral seam:
- Agent code can stay ignorant of credential mechanisms.
- Agent and Agent Deployment records survive changing runtimes.
- An enterprise-selected issuer can consume portable runtime evidence.
- Task approval creates a durable, revocable record.
- Every consequential action joins back to that record.
- The resource can always narrow or deny upstream authority.
Essay 2 carries the five identity-binding questions in full, and Essay 3 the six for the approved-work record.
The floor is written for the enterprise, and the contests will not resolve the same way everywhere. In a heterogeneous estate, procurement leverage and the portability demands above favor independent records. In a single-vendor estate, the bundle can be the rational choice, made deliberately rather than by default, which Essays 2 and 3 both concede. The open world has no procurement lever at all. Harness distribution and resource recognition favor platform issuers there, and the floor compresses to one test on the watch list below, whether a resource of consequence accepts task-bound credentials from an authority it does not operate.
What to Watch
The essays hedge honestly, so the hedges deserve instruments. Eight observable events would show which way the contests are breaking:
- Enterprise-Managed Authorization acceptance appearing beyond the launch consortium, or stalling inside it.
- A second identity provider entering the Cross App Access path in production.
- An Agent record demonstrably surviving a runtime migration with its policy and audit history intact.
- A shared, cross-vendor form for the approved-task record emerging in an MCP extension or an OpenID profile.
- Harness session state growing lifecycle and export APIs, the harness play reaching for the record.
- A resource of consequence accepting task-bound credentials from an authority it does not operate.
- A major runtime restricting agent egress to its own ecosystem’s endpoints, the platform block arriving as architecture rather than policy.
- Enterprise platform teams standardizing on model-routing gateways and portable memory stores, the buyer side building its own decoupling layer.
None of these requires a prediction. Each is a fact the market will either produce or fail to produce.
The Ladder
The provider seam decides how credentials are acquired and presented. Runtime evidence says which instance controls the key. The binding layer says whose Agent it is and which deployment was approved. The approved-task record says why authority exists and when it ends. An issuer projects those facts into credentials, and only projects them. The resource still decides whether one concrete action may proceed. Distribution sets the first three defaults. Standards keep their seams contestable. The adoption wedge decides whether those seams arrive in time.