Delegated / attenuated authority for MCP agent tool calls

Start by reviewing the architectural question in this issue and the linked OAAF implementation. Compare the proposed delegated-authority profile with this repository’s existing MCP authorization extensions and governance process. Done would require maintainer agreement on whether this belongs here before a narrowly scoped proposal or PR can be defined.

I’m working on OAAF (Open Agent Authority Framework), an open interoperability framework for delegated authority across AI agents and tools.

We’ve implemented an MCP enforcement profile where delegated authority is verified before the normal MCP authorization/PDP path. The authority can be narrower than the underlying credential, so an agent with valid credentials can still be denied a tool call that wasn’t delegated to it.

For example:
Agent credential:
broad repository access

Delegated authority:
repo.read
repo.write

MCP tools/call:
repo.merge

OAAF authority precondition:
DENY

Downstream PDP/tool:
never invoked

The goal is specifically not to replace MCP authorization or introduce another competing credential format. OAAF profiles existing standards for delegated/attenuated authority and composes with the normal MCP authorization path.

We have a working TypeScript/Python implementation, MCP/COAZ binding, portable conformance corpus, and implementation-independent conformance runner:

OAAF: https://github.com/espradley/oaaf

Before proposing an extension or SEP, I’d appreciate maintainer feedback on the architectural question:

Does delegated/attenuated agent authority belong as an optional MCP authorization extension in this repository, or would maintainers prefer it remain an external interoperability profile layered ahead of MCP authorization?

If this is in scope here, I’d be happy to prepare a narrowly scoped proposal/PR following the project’s governance process.