Delegated / attenuated authority for MCP agent tool calls

Open

#32 opened on Aug 19, 2026 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty: 5/5
Estimated time: Over a week
Newbie friendliness: 25/100

Issue type: Feature
Clarity: Needs clarification
Activity status: Quiet
Tech stack: python, typescript
Domain: authorization

Research direction

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.

Written by the indexing model from the issue text.

Description

enhancement

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.

Dominant language: MDX
Stars: 164
Forks: 54
PR merge metrics: No merged PRs in 30d

Contributor guide

Open the contributing guide

First steps

Read the whole issue, then the project's contributing guide.
Comment on the issue to say you are picking it up — it saves two people doing the same work.
Fork the repository and make your change on a branch.
Open a pull request that references the issue number.

Similar issues

False positive: TurkScan.com / TurkChain network Open

blocklist removal

Difficulty 2/5 1-3 hours Newbie friendliness 65/100

MetaMask/eth-phishing-detect#296544 · Opened Sep 23, 2026
Usage of curl in mcr.microsoft.com/azure-functions/dotnet-isolated:4-dotnet-isolated10.0 Open

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

Azure/azure-functions-docker#1257 · Opened Sep 23, 2026
build_ca_bundle.py: cap the privileged read size of the swapd-controlled CA Open

area:proxy bug security severity:low track:open-source

Difficulty 2/5 1-3 hours Newbie friendliness 75/100

ntindle/spark-vm#300 · Opened Sep 23, 2026
versions endpoint passes commit_hash to git show unvalidated: option injection (read tier, root-level entries) Open

bug server

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

markramm/pyrite#333 · Opened Sep 23, 2026
normalizeFilePath() leaks the username whenever the viewing OS differs from the machine the path came from Open

Difficulty 2/5 1-3 hours Newbie friendliness 70/100

bytedance/UI-TARS-desktop#2009 · 1 comment · Opened Sep 23, 2026

More Security issues