How security is actually applied to an AI data layer. You cannot trust an AI agent on data you don't govern. The controls that decide whether an agent is trustworthy sit below the model — at the data layer — and either they can produce evidence or they can't. This brief maps the seven that make an AI data foundation auditable.
Most AI-security conversations start at the wrong layer. Prompt filters, output moderation, red-teaming the model — all useful, all insufficient. The layer that decides whether an agent can be trusted is the one it stands on: the data, the tools, and the access path beneath it.
The frontier labs make the point explicit in their own shared-responsibility models: the vendor secures the model, and everything else — the tools, the data access, the environment the agent operates in — is yours. That "everything else" is the data layer. It is also where the industry has quietly converged on how to secure it. Microsoft governs data at a unified catalog with identity-anchored usage rights. SAP's architecture reuses the source system's own authorizations at the semantic layer rather than inventing parallel ones. OpenAI's internal data agent is strictly pass-through — it inherits existing permissions and cannot create new access. NIST classifies prompt injection and data poisoning as information-security risks, not model quirks. And the Cloud Security Alliance has published both a purpose-built threat model for agentic AI and a controls matrix that maps to NIST's framework.
This brief distills that convergence into seven controls, positions them against the published patterns, and shows where — in real agent deployments — the data layer is exactly where trust breaks. The thesis in two sentences: an agent is only as trustworthy as the layer it stands on, and that layer is trustworthy only if it can produce evidence on demand. Everything below is a way of asking whether yours can.
Distill the vendor architectures, the standards, and the frontier-lab engineering guidance, and you get seven controls. When we evaluate an AI system's data layer, these are what we look for — and what any serious implementation must demonstrate, not merely document.
Every agent has a verifiable identity from a single authority — not a scattering of API keys. Credentials are short-lived, scoped to the task, and every identity has a named owner. Readiness: rotation and revocation are scheduled operations, not incident responses.
No agent sees any data unless an explicit rule grants it — enforced by the access path at the moment of retrieval, not by a policy document or a pop-up. Telemetry shows most human permission prompts are approved without being read. Readiness: structural enforcement doesn't get tired.
Modern systems are chains: an orchestrator delegates to a sub-agent, which spawns a worker. At every hop authority can only shrink, and the human behind the request bounds the whole chain. Readiness: the full delegation chain travels with every request and lands in the audit log.
Source-system credentials — database keys, service accounts, API secrets — live only inside the governed gateway, injected server-side per request. The agent's process never contains them. A fully compromised agent cannot exfiltrate a credential that never entered its address space. Readiness: this single control eliminates the largest credential-theft class in agentic systems.
Indirect prompt injection — a poisoned document that steers the agent's next action — is an information-security risk, per NIST. Everything retrieved is treated as untrusted content, provenance-stamped at source, and structurally prevented from being read as a command. Readiness: the most dangerous input to an agent is often the data it just fetched.
Every response carries its sensitivity label, and anything derived from it — a report, a summary, a dashboard — inherits the highest sensitivity of its inputs. Viewing data and feeding it to a model are distinct rights. Readiness: an ungoverned summary of confidential data is still confidential data.
Grants and denials alike are recorded with identity, delegation chain, data classification, and a machine-readable reason code. Then the log itself is continuously analyzed for oversharing and anomalies — denials are the signal. Readiness: a write-only audit log is compliance theater; a monitored one is a control.
Any one of these can be pointed to on a slide. What separates an auditable data layer from a documented one is that all seven are enforced on one path that every agent request must traverse — and that the path emits evidence. An agent can be individually well-behaved and still fail its evaluation if the layer beneath it can't demonstrate these on demand.
The controls in §2 are not new. They exist across vendor documentation and standards today. The difference that matters is whether they run as separate native features — or as a single governed path an agent cannot go around.
These are generic patterns, not any one deployment. In each, the agent is competent and the model is fine. Trust breaks below it — at the layer that decides what the agent may touch and whether anyone can prove what it touched.
Named capability: a retrieval copilot wired to the ERP and the data warehouse so analysts can ask for balances, variances, and drill-downs in natural language. What it does well: the model reasons cleanly and cites the rows it used. The gap: the copilot authenticates as one shared service account that can read the whole ledger, so a junior analyst's question and a controller's question hit the same all-seeing identity — and the answer inherits no sensitivity label, so a summary of restricted accounts lands in an unrestricted chat log. Controls 01, 05 and 06 are where it fails, not the model.
// Shared closing shape: the agent behaves; the layer beneath it cannot answer who asked or who may see the output.
Named capability: an autonomous agent that watches telemetry, opens tickets, and can execute remediation runbooks — restart a service, rotate a config, scale a pool. What it does well: it triages fast and delegates sub-tasks to worker agents. The gap: delegation doesn't narrow — a worker spawned to read logs inherits the orchestrator's write scope, and the runbook it fetches is trusted as instructions rather than data, so a poisoned log line can steer an action. Approval prompts exist, but telemetry says they're waved through unread. Controls 02, 03 and 04 are the failure surface.
// Shared closing shape: the agent behaves; the layer beneath it lets authority widen and lets fetched content give orders.
Named capability: a public-facing RAG assistant grounded on help-center articles, policy PDFs, and a slice of the CRM so it can resolve customer questions. What it does well: grounded, on-brand answers with citations. The gap: the retrieval corpus was loaded as a free-for-all — an internal pricing memo and a stale policy draft sit in the same index as the public FAQ, with no provenance stamp and no deny-by-default at retrieval — and every grant and denial is written to a log nobody watches. The assistant will cheerfully surface what it can reach. Controls 02, 04 and 07 are the gap.
// Shared closing shape: the agent behaves; the layer beneath it has no door and no watcher.
// Three contexts, one pattern: in none of them is the model the problem. The trust decision lives in the data layer, and in each case it either can't be enforced or can't be proven.
Not an accusation — a diagnostic. If you can answer each of these with evidence, your data layer is in good shape. If a question stalls, that stall is the gap worth closing first.
If the answer is "several systems mint keys and no one is named on them," controls 01 and 05 are open. A verifiable identity with an owner is the anchor everything else hangs on.
If the honest answer depends on a human noticing a prompt, that's control 02 unmet. Deny-by-default should be enforced by the access path, not by attention.
If a sub-agent can exceed its parent, or retrieved content can steer an action, controls 03 and 04 need work. Authority should only narrow; content is never a command.
If the log is write-only, or a summary of restricted data loses its label, controls 06 and 07 are gaps. A monitored log and inherited sensitivity are what make "assume breach" real.
We evaluate AI agents and the data layer beneath them, then keep that evidence current. Not a model, not a governance platform — the layer between them.
A point-in-time assessment of the seven controls against artifacts and live tests — published identity documents, real denial logs, demonstrated bypass resistance — scored by NGIQ-ATE: 126 checks across six domains, multi-model consensus so no single AI decides the outcome. Result: an evidence-backed map of where trust holds and where it breaks.
A point-in-time certificate ages badly in a field that changes monthly. Control 07 is why: we monitor the audit log itself as the evidence stream, re-scoring as your agents and data change, so trust is a live posture — not a PDF from last quarter.
// Every numeric claim in this brief is tagged and must be verified against the cited primary source before publication. Only NGIQ-ATE's own parameters — 126 checks across six domains — are asserted directly. No figure here should be published as fact without confirmation from its source.
This is a living security reference. The seven controls are stable; the numbers, standards, and vendor patterns around them move. When a material shift lands — a revised standard, a new figure, a changed vendor posture — we log the delta below with citations rather than silently rewriting the body. The baseline entry records the assumptions the whole brief rests on.
Three assumptions underpin everything in this brief. If any of them is wrong, the brief is wrong — so we state them plainly and version them. Everything else — the seven controls, the two reference architectures, the diagnostic questions — is downstream of these.
Close · The question, answered — and the next one
"Agent trust lives below the agent, and it is real only when the layer beneath it can produce evidence on demand."
So the durable question isn't "is the model safe?" — it's "can your data layer prove what your agents touched, and would it have said no?" Ask it before something else asks it for you.