MCP database authorization contracts: test policy drift across every front door
The same database tool is exposed through an internal IAM gateway and an external OAuth gateway. Both authenticate correctly. Six weeks later, one path rejects a cross-tenant filter while the other accepts it.
The failure is not authentication. It is authorization drift: two front doors evolved around one capability without one testable contract.
Separate caller authentication from operation authorization
IAM signatures and JWT validation establish who the caller is. They do not by themselves decide whether that caller may invoke this tool, against this tenant and environment, with these arguments and result limits.
Keep that decision in a policy layer outside the model. For the wider control model, see the secure AI database access checklist.
Define one canonical authorization contract
Give every protected operation a stable capability ID. The contract should bind principal attributes, tenant/environment scope, allowed tool and argument shapes, approved views, row and byte limits, time windows, redaction profile, approval requirement, and policy version.
Gateway-specific configuration should compile or map from that source. Do not maintain an IAM rule, an OAuth scope table, and a database permission document as unrelated truth.
Return decision evidence
Each invocation should record the authenticated principal, credential type, capability ID, normalized resource scope, policy and tool versions, allow or deny result, matched rule, limit profile, and trace ID. Keep tokens, secrets, and raw sensitive rows out of the record.
Connect this evidence to query provenance so a reviewer can reconstruct both authorization and observation.
Replay one negative-test matrix everywhere
Run the same fixtures through every entrance:
- valid principal with another tenant's identifier;
- valid token with stale or missing scope;
- resource substitution after authorization;
- tool alias that bypasses a name-based rule;
- oversized range, rows, or result bytes;
- revoked principal and rotated signing keys;
- policy update while a request is queued;
- prompt text attempting to widen scope.
Compare structured decisions, not only HTTP status codes. A denial for the wrong reason can hide a gap that appears after the next configuration change.
Test policy rollout and rollback
Evaluate old and new policy versions side by side against recorded, redacted fixtures. Report changed decisions before deployment. Roll out with a version watermark in traces, monitor mismatches by front door, and keep a bounded rollback path.
Concrete acceptance criteria
- Every entrance resolves to the same capability vocabulary.
- Tenant and environment come from trusted context.
- Arguments are authorized after normalization.
- Database roles and views reinforce the gateway decision.
- The shared negative suite produces equivalent outcomes.
- Every decision exposes its contract version.
- Drift blocks rollout instead of becoming a runtime surprise.
Where Conexor fits
Conexor provides MCP infrastructure for connecting AI clients to databases and APIs through governed tools. A versioned authorization contract helps teams keep identity, scope, query limits, and evidence consistent as access paths multiply.
Explore secure MCP database access
For least-privilege execution, see read-only database access for AI agents.