What the current specification says

The MCP authorization specification dated 28 July 2026 describes authorization for HTTP transports. It treats a protected MCP server as a resource server and requires it to validate that access tokens were issued for that server. The specification also describes scope selection and least-privilege access. These are protocol requirements within its stated scope; they do not make every MCP integration secure automatically.

That distinction matters when an organisation gives an agent an identity. Recognising the caller does not answer which customer records it can read, what it can change, or whose approval is needed. A passport is evidence about identity, not a universal access token.

The older lesson that still applies

NIST’s Zero Trust Architecture, published in August 2020, separates authentication and authorization and rejects implicit trust based solely on network location or ownership. It predates today’s agent tooling. Applying its resource-focused approach to agents is our engineering interpretation, not a claim that NIST endorses Fisemarco.

Consider an agent assigned to prepare a supplier-payment draft. It may legitimately read a specific invoice and produce a recommendation. That does not imply permission to change bank details, approve the payment, or instruct a second agent to do either. Those are distinct actions at distinct resources.

What builders should test

At the protected tool, check the current identity, the intended resource, the allowed operation, the authority chain and expiry. Then test a denied request and confirm that it never reaches the resource. Testing only a successful API response leaves the important boundary unproven.

Repeat that test after revocation and with an expired permit. Where retries are possible, check that the same authorization cannot accidentally cause the effect twice. Treat model-generated instructions, tool results and public profiles as data; none should grant new privileges by themselves.

Where Fisemarco fits - and where it stops

Fisemarco connects persistent runtime identities with signed records, bounded delegation and task-permit checks in participating integrations. Its SDK provides a path for checking authority before protected work. The operator must connect that path to the actual resource and test the integration; a directory entry cannot enforce it.

A signature can establish that a key signed a record. It cannot by itself prove an employee’s affiliation was independently checked, that an agent’s answer was correct, or that the reported real-world action happened. Evidence should state precisely what was observed.

Our view is straightforward: make identity portable, make authority explicit, and make denials observable. The useful question is not simply whether an agent has a passport. It is whether the system can explain - and enforce - why this agent may perform this particular action now.

Sources and reading

  1. MCP authorization specification, 28 July 2026Checked 15 October 2026
  2. NIST SP 800-207: Zero Trust Architecture, August 2020Checked 15 October 2026

AI-assisted analysis, checked against the primary sources linked below. This is technical commentary, not legal advice or a certification statement.

Spotted an error? Send a correction.