Summary

  • A 2 November individual IETF draft proposes /.well-known/agent-capabilities as the place an application declares its agent flows, authorization servers and invocation surfaces.
  • Under its rules, an operation missing from every advertised flow is closed, even if a previously approved authorization instance includes it. The draft warns that replacing the static document can redirect agent planning without a code change.

The application can sit still while its agent entrance moves. In the new scenario-discovery and authorization draft, a JSON document under /.well-known/agent-capabilities tells an agent which operations exist, where to invoke them and which authorization servers to approach. That ordinary-looking publication point becomes a decision surface. An operation absent from every advertised flow is closed by default. The resource server must not execute it, even when an approved authorization instance lists it; the authorization server should decline an instance that contains it.

This gives an operator a clean way to withdraw a flow. It also makes ownership of a static file a serious governance question. Section 8.6 says an attacker with write access to an origin's static content could replace the document and steer newly arriving agents toward chosen invocation surfaces or away from genuine flows. The application code need not change. The authors recommend putting the file under the same release change control as the application. RFC 8615 already warned that administrators may overlook /.well-known paths; this proposal would place executable exposure behind one of them.

The native-app rule makes the hierarchy sharper. A package may carry a cached capability document for offline discovery. Before its first remote operation in a session, the app checks the copy served by its associated origin. If they differ, the origin's version wins. A flow removed there cannot be executed merely because an old package still advertises it. An app-store release therefore cannot, on its own, preserve access to a withdrawn operation.

The proposed document also lists authorization-server issuers and invocation surfaces. Its display name and logo are expressly presentation data, not identity proof; origin and authenticated delivery do the binding. Where the app publishes OAuth Protected Resource Metadata, the draft requires its authorization-server list to match. A mismatch is a concrete signal that the public pointers disagree.

The IETF record identifies this as an individual draft, updated 2 November. The missing fact is a named deployment's file history and enforcement logs: those would show whether this proposed switch has actually controlled a live agent request.