Sangam,
Thank you -- your two predicates are exactly right, and the first of them
(list_dir as a class grant until argument bounds exist) was a fair reading
of the v1.0 vector. I took your observation as the trigger to close the
gap: std/mcp-v1 is now v1.1.0 and carries per-tool argument bounds, and the
gateway plugin enforces them.
Certificate parameters (v1.1.0):
{"tools":["read_file","list_dir"],
"tool_args":{"read_file":{"path_prefixes":["/workspace"]}}}
Updated decision table:
tools/call read_file path=/workspace/src/a.txt ALLOW (200)
tools/call read_file path=/etc/shadow
DENY (403)
tools/call bash
DENY (403)
tools/call delete_file
DENY (403)
tools/call list_dir path=/etc
ALLOW (200) [class grant]
initialize / ping / tools/list
no tools/call decision
So the two predicates are now exercised separately: tool identity
(bash/delete_file denied by the allowlist) and argument subset (read_file
denied when the path escapes the certificate-bound prefix). Your framing --
"only the set of certificate-bound fields expands" -- is exactly what
happened: same enforcement model, new field.
Pinned updates:
- capability: e76c241 (std/mcp-v1 v1.1.0)
- gateway-core: v0.4.5 (mcp plugin argument-subset)
- gateway: bca551d
- demo: 764b012 (scenario-demo.py --scenario mcp runs the updated matrix)
build.sh now builds all binaries from pinned commits in one command, so the
reproduction path is: clone, ./build.sh, setup, run.
Happy to keep the write-up with the four-row table plus the two predicates
separate, as you suggested.
Best,
Jijie Wei_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
