Agent-Ready Means Governed: From GUIs to Permissioned APIs

The integration costume is convincing. Teams treat agent-readiness as a checklist of formats. Publish structured data. Expose an endpoint. Document the schema. Useful work, but it answers the wrong question. The question is not "can an agent reach my system." It is "what is an agent allowed to do once it gets there, and how do I prove what it did."

That reframing matters because an agent is not a deterministic script. It interprets. It improvises. It can be steered by content it reads along the way. So the controls you wrap around it are not nice-to-haves layered on top of a working API. They are the product. A governed interface answers three things before it answers anything else: what permissions does this agent hold, what requires a human to confirm, and what record binds each action to the reasoning that caused it.

The strongest evidence that agent-readiness is governance comes from the people building the connection layer. The Model Context Protocol specification, revision 2025-06-18, makes four security principles normative. Users must explicitly consent before any data access or tool invocation. Tool descriptions and annotations are to be treated as untrusted unless they come from a trusted server. Hosts must obtain explicit user consent before exposing user data to servers. And users must explicitly approve any model sampling request. The spec is candid that it cannot enforce these at the protocol level, so it instructs implementors to build the consent and authorization flows themselves.

Read that again as a business statement. The standard for connecting agents to your systems is, at its core, a consent-and-authorization standard. It treats the descriptions an agent reads as hostile until proven otherwise. It puts a human approval step in front of tool calls by design. That is not how you describe a coding task. It is how you describe a governance regime.

The authorization layer is where the governance turns concrete. The MCP authorization specification is built on OAuth 2.1 and mandates PKCE, audience-bound tokens through RFC 8707 Resource Indicators, RFC 9728 Protected Resource Metadata, and RFC 8414 Authorization Server Metadata. It recommends RFC 7591 Dynamic Client Registration. Worth noting that OAuth 2.1 itself is still an active IETF draft, draft-ietf-oauth-v2-1, rather than a finalised RFC, and MCP layers PKCE and HTTPS-only transport on top of it.

Two rules matter most to a business: scope and passthrough. Token passthrough is explicitly forbidden. A server must validate that a token was issued specifically for it, not simply accept a token that happens to be valid somewhere else. The spec calls out the confused deputy problem by name, the failure mode where a privileged component is tricked into using its authority on behalf of an attacker. In plain terms: an agent holding a key to one room must not be able to use it to open every door in the building. That is a permission boundary an agent cannot escape, written into the standard as a requirement rather than a suggestion.

The governance reflex is not unique to protocol designers. GDPR Article 22 gives a data subject the right not to be subject to a decision based solely on automated processing, including profiling, where that decision produces legal effects or similarly significant effects. Where an exception applies, through contract necessity, EU or member-state law, or explicit consent, the controller must implement safeguards. Those safeguards include the right to obtain human intervention, to express a point of view, and to contest the decision.

Look at what the law asks for and what the protocol asks for. Both want a human able to step in before a machine decision lands with force. The governed API is where that legal right stops being a clause and becomes a runtime control. A confirm step in front of a consequential action is the Article 22 right to human intervention, implemented in code. An audit trail that binds an action to its cause is what lets you contest a decision after the fact, because you can see what the agent did and why. The compliance language and the engineering language are describing the same checkpoint.

So strip away the costume and state the requirement plainly. A business is agent-ready when an external agent can do three things, and only three things, in this order. First, it can discover machine-readable context about your business, where the formats are still settling. Structured data through schema.org, a community vocabulary founded in 2011 by Google, Microsoft, Yahoo, and Yandex rather than a ratified W3C standard, is the mature option. llms.txt, proposed by Jeremy Howard in September 2024, remains open for community input, not a settled standard. Treat both as inputs to discovery, not as the finish line.

Second, it can act through scoped permissions it cannot escape, with a confirm step before anything consequential leaves the building. Third, every action it takes is written to an audit trail that binds the action to the reasoning that produced it. Discovery is the part that looks like the work. Scoped authority and the audit trail are the part that is the work. A business that has published structured data but cannot answer "what is this agent permitted to do, and how would I prove what it did" is discoverable, not agent-ready.

Origin Pi builds the governed business layer that sits between an external agent and your operations. The brief above is the design spec for it: machine-readable context an agent can find, scoped permissions an agent cannot exceed, a confirm step in front of consequential actions, and an audit trail binding every action to its cause. That is the difference between an endpoint and a governed one. See agent-readiness for how we assess where your business stands today, and the agentic business layer for the governed brain that gives outside agents a safe, permissioned way to act on your behalf.

• The Model Context Protocol specification revision 2025-06-18 makes four security principles normative (explicit user consent before data access or tool invocation; untrusted tool descriptions; consent before exposing user data to servers; approval of sampling), and states MCP cannot enforce them at the protocol level so implementors should build consent and authorization flows.
• The MCP authorization specification (2025-06-18) is based on OAuth 2.1, mandates PKCE, RFC 8707 Resource Indicators, RFC 9728 Protected Resource Metadata, and RFC 8414 Authorization Server Metadata, recommends RFC 7591 Dynamic Client Registration, forbids token passthrough, requires servers to validate token audience, and addresses the confused deputy problem.
• GDPR Article 22 gives a right not to be subject to solely automated decisions with legal or similarly significant effects, and where exceptions apply requires safeguards including human intervention, the right to express a point of view, and the right to contest the decision.
• schema.org is a collaborative community vocabulary founded in 2011 by Google, Microsoft, Yahoo, and Yandex, hosted in a W3C Community Group since 2015 but not a W3C standard.
• llms.txt is a proposal published by Jeremy Howard on 2024-09-03 advocating a /llms.txt markdown file for LLM-friendly content, still open for community input and not a ratified standard.