The approved tool catalog defines which MCP servers and tools are available to the gateway. Install-time catalog approval is necessary but insufficient -- it does not prevent an agent from calling a tool that is in the catalog but inappropriate for the specific workflow or task at hand.
The problem (P2.4):
The approved catalog contains delete_customer_record and send_customer_email. Both are correctly on the approved list. A customer-facing chat workflow has access to both. In the context of that workflow, calling delete_customer_record is catastrophic and should never happen. But the gateway only sees that the tool is in the catalog -- it has no per-workflow policy that further constrains which subset of catalog tools are reachable for this specific workflow.
What per-workflow scope provides:
A workflow-level Cedar policy narrows the allowed tool set for a given agent session or task type. The workflow policy is evaluated in addition to (not instead of) the catalog-level policy. A tool call requires passing both: catalog policy (tool is registered and allowed) AND workflow policy (tool is in scope for this task).
Design questions:
- How is the workflow identified at policy evaluation time? (session metadata, agent header, explicit workflow tag in the tool call)
- Can workflow policies be dynamic (agent declares its current workflow) or must they be static (workflow is determined by deployment configuration)?
- What does the workflow policy expression look like in Cedar? (role-based: this agent role may only call tools tagged data-read; task-based: during onboarding-workflow, only tools in the catalog subset onboarding-tools are reachable)
- How does the per-workflow policy interact with the catalog hash measurement? (both must be in the policy bundle to be measured)
OWASP: MCP02 (Privilege Escalation via Scope Creep -- install-time scope too coarse for runtime)
Output: Add workflow-level policy scope to the Cedar policy model section of docs/SPEC.md and the policy bundle format.
The approved tool catalog defines which MCP servers and tools are available to the gateway. Install-time catalog approval is necessary but insufficient -- it does not prevent an agent from calling a tool that is in the catalog but inappropriate for the specific workflow or task at hand.
The problem (P2.4):
The approved catalog contains delete_customer_record and send_customer_email. Both are correctly on the approved list. A customer-facing chat workflow has access to both. In the context of that workflow, calling delete_customer_record is catastrophic and should never happen. But the gateway only sees that the tool is in the catalog -- it has no per-workflow policy that further constrains which subset of catalog tools are reachable for this specific workflow.
What per-workflow scope provides:
A workflow-level Cedar policy narrows the allowed tool set for a given agent session or task type. The workflow policy is evaluated in addition to (not instead of) the catalog-level policy. A tool call requires passing both: catalog policy (tool is registered and allowed) AND workflow policy (tool is in scope for this task).
Design questions:
OWASP: MCP02 (Privilege Escalation via Scope Creep -- install-time scope too coarse for runtime)
Output: Add workflow-level policy scope to the Cedar policy model section of docs/SPEC.md and the policy bundle format.