An agent access policy is not real until the denied path fails on purpose.

Positive and negative paths both matter

AI-ready data is not only available data. It is data that can be reached through approved paths with metadata, policy, lineage, freshness, and failure behavior intact. That requires test suites, not just access reviews.

A useful access path suite tests approved tables, metrics, documents, APIs, and tools. It also tests blocked paths. The blocked path is where governance proves itself because the system has to deny access with enough evidence for the user, owner, and incident reviewer to understand what happened.

Core idea: AI-ready access tests should prove both allowed reachability and useful denial across every data path an agent can use.

Risk management needs repeatable tests

The NIST AI Risk Management Framework gives teams govern, map, measure, and manage functions for AI risk. The Open Policy Agent testing documentation shows how policy behavior can be tested directly.

ODI adds the data path. A test suite should verify source authority, catalog resolution, identity, policy, query execution, document retrieval, tool permission, and evidence returned to the agent. If any layer cannot be tested, that layer is still a trust assumption.

Patterns that work

  • Create test cases for approved, denied, expired, stale, and owner-review-required paths.
  • Test tables, metrics, documents, APIs, and tools as separate access surfaces.
  • Record identity, policy decision, source object, and returned evidence for each run.
  • Include negative tests in release gates for agent tools and retrieval systems.
  • Make denial messages useful without leaking restricted data.

For adjacent ODI context, read AI-ready data infrastructure, AI-ready policy test fixtures, and ODI control planes for AI workloads.

What breaks first

  • The team tests only the happy path and discovers policy gaps in production.
  • Denied access returns a generic error that nobody can trace to a policy decision.
  • Document retrieval follows different rules from table access.
  • A new tool ships without test cases for stale, revoked, or owner-restricted data.

Questions to ask

  • Which data paths can an agent use, and which ones are explicitly blocked?
  • Can each access decision show identity, policy, source, and reason?
  • Do negative tests run before agent-tool releases?
  • Can data owners add tests when policy or source authority changes?

Sources to start with

These primary sources anchor the technical claims in this guide.

AI-ready access is not the path that works. It is the path that works and fails with evidence.