Resource access checker

Resource access checker

What it does: Pipeline step that decides whether an agent's tool call may touch the requested resource (schema, asset, table).

1. Vision context

The Collibra demo's headline moment is "schema X allowed, schema Y read-only, schema Z denied." That's this component. Operationally: a pipeline step keyed on the tool's args. When the agent emits delete_asset(asset_id, schema=pii_archive), this step looks up pii_archive in the keyring's schemas_acl, sees it's denied, and rejects the call before it reaches the upstream.

Generic enough to apply to any tool with a "resource scope" arg — schemas, projects, repositories, accounts. Not Collibra-specific.

2. Functional specification

Input: (tool_call, keyring) where tool_call has structured args.

Logic: match args against keyring.layer_4_mcp.capabilities.schemas_acl. Apply the most specific rule (deny > allow). Return decision + reason + layer + provenance.

Output: Decision(action: allow | deny, reason: str, layer: "mcp", provenance: ProvenanceEntry).

3. Technical design

Standard pipeline step shape (consistent with intent-to-policy substrate). Lives at tappass/gateway/pipeline/steps/schema_acl.py.

4. Definition of done

• All acceptance_criteria pass.
• Tested against customers (RW), finance (RO), pii_archive (DENY) mock from collibra-reference-agent.
• Denial audit row includes provenance.

5. Coordination notes

With policy-to-sandbox-config-builder: schema for schemas_acl is owned by the builder; we consume.

Open questions:

• (Q) What's the arg-matching language? Lean: simple key match for v1 ({schema: "pii_archive"}); JSONPath for v2.

6. Out of scope

• Authoring the ACL rules — operator does that via intent-to-policy categories/concerns.
• Per-tool argument validation beyond resource scope (PII detection, etc. are other pipeline steps).