Repository navigation
Prove that identity named in a tool's input never becomes ctx.caller - #58
Merged
Merged
Conversation
#15 asks that substituting member, organization or approver identifiers cannot impersonate another principal. The caller scenario now has a tool whose input carries a forged caller (another member's subject, a foreign organization) and a forged approver. The member's call still sees their own verified caller and no approver.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Acceptance evidence for #15 (identity). This only adds assertions; no product code changes.
#15 requires that "substituting member, organization, or profile identifiers cannot impersonate another principal". The host sets
ctx.callerand never reads it from input, but no scenario showed that.Change
caller-identity.spec.ts(scenariocallerIdentity): the test app gains aclaimquery whose input carries acallerand anapprovedBy. Alice (a member) calls it with Bob's verified caller, a foreignorganizationId, the owner's email, and a forged human approver. The app still sees exactly Alice's verified caller and no approver.The rest of #15, already covered by existing scenarios (run on the merged tree today)
caller-identity.spec.ts: "apps see each MCP user, the dashboard person and workflow work as distinct verified callers"claimassertionsmember-api-keys.spec.ts: "Organization membership removal permanently revokes pinned API keys";warm-request-auth.spec.ts: "Dashboard requests refuse signed-out sessions and removed members immediately"mcp-grant-restrictions.spec.ts: "MCP grants retain exact selections through deploys and live narrowing" (a tool added by a later deploy,later, and a hidden app are both refused under the existing selection)Self-host: 4 passed.
bun run checkpasses.