Tejus Rachakonda
9acd84b910
Plain-terms companion to integration-architecture.md: Automation Hub as the internal action warehouse, Tool Hub as the smart front desk (progressive disclosure + per-user permission filtering + audit) running as a central service, and where the MCP Gateway (Arcade, per-user OAuth for outside tools) and AI Gateway (config-only model toll booth) plug into existing seams. Source-verified against servicetitan/tool-hub + automation-hub @ master.
5.4 KiB
5.4 KiB
Category 3 — Tool-Level Access Control and Policy (weight 15)
Verbatim criteria/gates from the criteria Google Doc. Fill Score/Evidence locally; the human pastes. 1–5 scale; anchors at 1/3/5.
Scores
| # | Criterion (verbatim) | Score (1–5) | Evidence / note |
|---|---|---|---|
| 1 | Tool-level allow-list per user — a user can only call tools explicitly granted to them; the gateway enforces this, not the client. | ||
| 2 | Contextual Access rules — per-user tool visibility and invocation policy layered on top of the gateway allow-list. | ||
| 3 | Input filtering — ability to block or rewrite tool inputs based on policy before execution reaches the server. | ||
| 4 | Output redaction — ability to mask or strip sensitive fields from tool outputs before they reach the agent. | ||
| 5 | Policy is enforced at the Engine, not the client — a malicious or compromised client cannot bypass it. | ||
| 6 | All policy decisions (allow, block, redact) are logged. | ||
| 7 | Per-user tool grants can be updated without restarting the gateway or any server. | ||
| 8 | Gateway scopes map to Okta groups — access managed in Okta, not a separate system. |
Average: ___ Category score: ___
Score anchors
- 1 — Gateway-level tool list only; no per-user scoping or input/output policy
- 3 — Per-user grants work; Contextual Access input/output rules require significant manual work
- 5 — Full per-user policy, Contextual Access input/output rules, Okta-managed scopes, all decisions audited
Benchmark tests
| # | Test (verbatim) | Result | Evidence |
|---|---|---|---|
| 1 | Grant User A access to GitHub tools and User B access to Atlassian tools. Verify User A cannot invoke Atlassian tools even if they know the tool name. | PARTIAL (curr-state) — on one gateway the tool list is gateway-wide, identical for A and B (not per-user); an ungranted/unknown tool is cleanly rejected at the Engine. True per-user grant (A=GitHub, B=Atlassian) needs 2 gateways or Contextual Access (dashboard). | probes.md §B1: A==B 10 tools; Github_CreateIssue → McpError: tool not enabled for this gateway |
| 2 | Write a Contextual Access rule that blocks inputs containing a specific pattern (e.g., a mock SSN). Send a matching input — verify it is blocked before execution and logged. | ||
| 3 | Write a Contextual Access rule that redacts a field from tool outputs. Verify the field is absent from the agent's response. | ||
| 4 | Update User A's tool grants (add a new tool). Verify the change takes effect without restarting anything. | ||
| 5 | Confirm policy enforcement point: attempt to bypass Contextual Access by calling the server directly (bypassing the Engine). Confirm this is architecturally prevented or explicitly documented as a known boundary. | DONE — enforcement is at the Engine. All arcade Services are ClusterIP; the worker (where tools run) is not public → public bypass network-prevented. In-cluster direct-to-worker is reachable but secret-gated (operational). Self-hosted custom servers exposed via public tunnel are a documented bypass boundary. | probes.md §B5: svc types; worker /worker/health=200, /mcp=406 (needs secret) |
Suggested pass/fail gates
| Gate | Pass condition (verbatim) | Result | Evidence |
|---|---|---|---|
| Tool isolation | Cross-user tool calls are rejected at the Engine regardless of client behavior | PARTIAL — ungranted/unknown tools are rejected at the Engine (not the client); but on one gateway the allow-list is gateway-wide, so it is not yet per-user isolation. | probes.md §B1/§B5 |
| Input policy | Blocked inputs are rejected before execution, not after | ||
| Output policy | Redacted fields are absent from the agent's response | ||
| Audit | Every policy decision (allow/block/redact) produces a retrievable log entry | ||
| Dynamic grants | Tool grant updates take effect without service restart |
Findings
- Enforcement point = the Engine (criterion 5). Ungranted/unknown tool calls are rejected at the Engine with a clean structured error (
tool not enabled for this gateway) — no leak, no execution, no shared-credential fallback. - Tool curation is per-gateway, not per-user (criteria 1, 2). On a single Arcade-Headers gateway the tool list is identical for every
Arcade-User-ID(A==B). Per-user differentiation requires Contextual Access (an access hook) or separate gateways / a User Source — to be tested once dashboard access lands. - Bypass surface (criterion 5 boundary). Public attack surface is network-isolated for in-cluster tools (worker is ClusterIP). Two documented boundaries: (a) in-cluster direct-to-worker is only secret+network gated (operational, not architectural); (b) self-hosted custom servers exposed via public Cloudflare tunnel can be called directly, bypassing Engine policy — mitigate in prod via ClusterIP registration / tunnel access control.
- V4 seam note. With no ToolHub deployed, all of the above is Arcade-native enforcement. For a ToolHub front, the authority decision + audit (
ToolHubDecisionRecord) would move to the ToolHub MCP Endpoint, and Arcade should be reachable only via ToolHub (closes boundary (a)/(b)). - Pending (dashboard / Contextual Access): per-user grants (1), Contextual Access input block (3) + output redaction (4), dynamic per-user grant w/o restart (7), audit of decisions (6), Okta-group scopes (8).