Layer 03 · AI governance
AI Data Security & Access Controls
Protect AI data, models, credentials and agents from misuse, leakage and attack.
Classic data security still matters: encryption, access control and key management. But AI introduces a new attack surface that traditional security controls were never designed to handle. Prompts can hijack instructions, model outputs can be treated as trusted, and AI agents can be given more access than their tasks require.
AI data security brings these protections together. It safeguards data at rest, in transit and in use while extending security controls to AI-native threats such as prompt injection, sensitive-data disclosure, excessive agency and AI agent tool poisoning.
Active defence
Data protected. Access controlled. Keys secured.
AI expands the attack surface through new data flows, model interfaces, credentials, agents and automated actions. Effective AI data protection requires organisations to understand what data AI systems can access, who or what can reach them, and how much authority each model or agent has.
This layer combines five foundational controls with AI-specific safeguards to protect sensitive information, models and systems throughout the AI lifecycle.
Illustrative figures for a representative estate.
01 · Where it begins
AI Data Security & Access Challenges
AI security goes beyond protecting a database or restricting access to an application. Organisations need to understand how data moves through AI systems, what models can access, and what an AI agent can do when something goes wrong.
Five questions determine whether an AI environment is properly protected. Each one points to a core control in this layer.
02 · The controls, explained
Five Controls That Secure AI
Effective AI data security combines established information-security principles with controls designed for AI-specific risks. Each control provides a distinct capability, from protecting data and credentials to limiting model and agent access.
Encryption
Protecting data at rest, in transit and in use.
Definition
Encryption prevents sensitive AI data from being exposed if storage, networks or infrastructure are compromised.
How it works
For AI systems, this includes training datasets, embeddings, prompts, model inputs, outputs, API traffic, application databases and backups.
How we help
Modern AI environments also need to consider protection while sensitive information is being processed. For high-risk workloads, encryption-in-use technologies can provide additional protection around data during computation.
What it protects
Training and inference data
Customer and employee information
Prompts and model outputs
Vector and embedding stores
API traffic
Model credentials and secrets
Data stored in cloud infrastructure
AI security extension
Encryption does not stop prompt injection or malicious model behaviour, but it limits the value of stolen data and strengthens the security boundary around AI workloads.
Anonymisation
Ensuring models see only the information they need.
Definition
The safest sensitive information is often information the model never receives.
How it works
Anonymisation, pseudonymisation and context minimisation reduce the amount of personal or confidential information exposed to AI systems. This strengthens AI data privacy while reducing the consequences of a model, application or agent being compromised.
How we help
Instead of sending an entire customer record to a model, an application can provide only the fields required to complete the task.
What it protects
Personal information
Customer records
Financial information
Healthcare information
Employee data
Confidential business information
Sensitive identifiers
AI security extension
Data minimisation also reduces the impact of prompt injection and data exfiltration because an attacker cannot extract information that the model never receives.
Role-Based Access
Controlling who and what can reach models and data.
Definition
AI access controls determine which users, applications, services and agents can interact with specific models, datasets, tools and systems.
How it works
ARole-based access control provides a structured foundation by assigning permissions according to defined responsibilities.
How we help
For more dynamic environments, organisations can extend this with attribute-based access control, evaluating factors such as identity, device, location, workload, sensitivity and context.
What it controls
Model access
Dataset access
Vector database access
AI tools
APIs
Production systems
Administrative functions
Agent capabilities
AI security extension
AI systems need identities of their own. An agent should not automatically inherit the permissions of the person who created it or the application in which it operates.
Least privilege
Minimising the blast radius and the risk of excessive agency.
Definition
Every AI system should have only the permissions required to perform its intended task.
How it works
Least privilege becomes especially important when AI moves from responding to users to taking actions. An agent with access to customer records, payment systems, email, databases and internal applications can create significant damage if its instructions are manipulated.
How we help
Permissions should therefore be scoped to the smallest practical set of resources and actions.
What it limits
Unnecessary system access
Agent capabilities
Tool permissions
Database operations
API access
Administrative functions
High-impact actions
AI security extension
Least privilege is the primary defence against excessive agency. When an AI system is compromised, restricted permissions limit what it can reach and what it can do.
Key management
Governing the secrets that protect everything else.
Definition
AI systems depend on credentials to access models, databases, APIs, cloud platforms and external services.
How it works
Poorly managed API keys can create both security and financial risks. A leaked model credential can expose sensitive information or allow an attacker to generate large volumes of model requests.
How we help
AI Secrets Management should therefore include secure storage, rotation, access control, monitoring and revocation.
Key controls include
Centralised secret storage
Automatic credential rotation
Per-service credentials
Key expiry
Access logging
Separation of duties
Emergency revocation
Usage and spend limits
AI security extension
Model credentials should be treated as production secrets, not application configuration. Every key should have an owner, defined scope, and clear lifecycle.
Threat coverage
AI-Native Threats × the Controls That Meet Them
Traditional security controls remain essential, but AI introduces threats that require additional safeguards. The matrix below shows how core security controls address common AI-native risks.
03 · A practical reference
AI-Native Threats and the Controls That Meet Them
Firewalls and encryption alone cannot stop a prompt-based attack or an AI agent from taking an unintended action.
These risks are specific to AI applications and require controls across data, models, applications, agents, and infrastructure. The following risks align with the OWASP Top 10 for LLM Applications (2026 edition, published 4 August 2026) and broader AI security practice. Agent-specific risks - including agent tool poisoning - are covered by the companion OWASP Top 10 for Agentic Applications (ASI 2026).
| Risk | What it is | Primary mitigations |
|---|---|---|
| Prompt injection LLM01:2026 | Malicious instructions in user input or retrieved content attempt to manipulate model behaviour. | Privilege separation, human approval, input validation and context minimisation |
| Sensitive-info disclosure LLM02:2026 | The model reveals personal information, credentials, confidential data or system prompts. | Anonymisation, least privilege and output filtering |
| Excessive agency LLM03:2026 | An AI agent has more autonomy, permissions or tool access than its task requires. | Least privilege, tool-scope limits and action gating |
| Supply-chain risk LLM04:2026 | Compromised models, datasets, adapters or dependencies introduce malicious behaviour, including hallucinated package names registered by attackers ("slopsquatting"). | Provenance, registry controls and dependency review |
| Data and model poisoning LLM05:2026 | Training, fine-tuning or embedding data is manipulated to alter model behaviour. | Data provenance, dataset validation and anomaly detection |
| Unbounded consumption LLM06:2026 | Runaway requests create denial-of-service or denial-of-wallet conditions. | Rate limits, spend caps, monitoring and key management |
| Misinformation LLM07:2026 | The model produces output that is wrong but credible enough to be acted on downstream. | Grounding, confidence scoring, cross-validation and human review of consequential outputs |
| Hidden context exposure LLM08:2026 | System prompts, retrieved policy text, tool schemas and other non-user-facing context are extracted and exposed. | Secrets kept out of context, output filtering and designing so disclosure has limited impact |
| Vector and embedding weaknesses LLM09:2026 | Retrieval systems or embedding stores are manipulated, or cross-tenant information is inferred from similarity search. | Vector-store access control, tenant isolation, anonymisation and encryption |
| Improper output handling LLM10:2026 | Model output is trusted, rendered or executed without validation, including into terminal, IDE and auto-fetching renderers. | Output validation, sanitisation and treating model output as untrusted |
Treat Model Output as Untrusted Input One of the most important principles in LLM data security is simple: model output should never automatically be treated as trusted.
An AI model can be influenced by malicious instructions contained in user prompts, documents, websites, retrieved information or tool responses. Its output should therefore be validated before it is executed, rendered into a sensitive application or used to trigger an action.
The same principle applies to AI agents. An agent should not be allowed to execute high-impact operations simply because a model generated the instruction.
03b · Standards mapping
Where Each Control Satisfies a Recognised Obligation
AI security draws on established information-security standards alongside AI-specific frameworks and guidance.
Mapping controls to recognised standards helps security, compliance and engineering teams connect AI security requirements with existing governance processes.
| Control | EU AI Act | AI security | ISO / other |
|---|---|---|---|
| Encryption | Art. 15 | OWASP LLM02 | ISO/IEC 27001 A.8 |
| Anonymisation | Art. 10 · 15 | OWASP LLM02 | ISO/IEC 27701 |
| Role-based access | Art. 15 | MITRE ATLAS | ISO/IEC 27001 A.5 |
| Least privilege | Art. 15(5) | OWASP LLM06 | ISO/IEC 42001 §8 |
| Key management | Art. 15 | OWASP LLM10 | ISO/IEC 27001 A.8 |
04 · What AI-ready security adds
Beyond Classic Data Security
Strong information security is necessary for AI, but it is not sufficient.
Generative AI data security introduces additional requirements because models can interpret untrusted instructions, generate unpredictable outputs and interact with tools and external systems.
A secure AI deployment therefore adds controls around the model and its surrounding ecosystem.
- Defence Against Prompt Injection Inputs, retrieved documents and third-party content are treated as potentially untrusted. Validation, context isolation and instruction hierarchy help reduce the risk of malicious instructions overriding intended behaviour.
- Untrusted Output Handling Model output is validated before it is executed, rendered into sensitive systems or used to trigger an action.
- Agent Identity and Scope Every AI agent has a distinct identity, defined permissions and limited tool-access scope.
- Action Gating High-impact operations require confirmation or additional controls instead of executing automatically.
- Consumption Limits Rate limits, quotas and spend caps protect against denial-of-service and denial-of-wallet attacks.
- Encryption in Use Sensitive workloads can use additional protection for data during processing, where appropriate to the risk and technology environment.
- AI Just-In-Time Access Temporary permissions can be granted only when an AI system or agent needs them, reducing the exposure created by persistent credentials and standing privileges.
From the white paper
When AI stops responding and starts acting, errors are no longer outputs. They become actions.
That is why guardrails become architecture rather than an afterthought. Least privilege becomes the blast-radius control for every AI agent. Action gating becomes a protection against unintended consequences. Monitoring becomes a way to detect abnormal behaviour before it becomes an incident.
Guardrails are enablers, not constraints.
Failure modes
How AI Access Control Fails
AI can widen the attack surface faster than traditional controls can adapt. Common failure patterns include excessive permissions, static roles and poorly designed agent guardrails.
The over-privileged agent
One agent has access to everything it might possibly need. If the agent is compromised or manipulated, the attacker inherits that reach.
Fix Apply least privilege, tool-level permissions and per-agent scope.Title-based access
A user's job title provides access to multiple models or datasets that are unrelated to their current task.
Fix Use attribute-based access control to evaluate identity, device, location, workload and context.No kill switch
An autonomous agent has no tested mechanism for stopping an action once execution begins.
Fix Implement fail-safe controls, emergency shutdown, rollback and safe fallback procedures.Guardrails bolted on later
Security controls are added after deployment instead of being designed into the AI architecture.
Fix Treat guardrails as deployment architecture and measure their reliability through incidents, false positives and operational testing.Illustrative failure patterns, not client-specific incidents.
The building blocks
Two ladders worth knowing
The vocabulary that separates mature AI access control from ordinary IAM.
The access-control ladder
The seven guardrails for agents
05 · In practice
Real-World AI Security Scenarios
AI security becomes clearer when applied to real operating environments. Each scenario below illustrates how security controls can address common AI data protection and access-control challenges.
Challenge
A retail bank's customer assistant retrieved information from internal knowledge articles. The organisation had not tested whether malicious instructions embedded in those documents could influence the model.
Controls applied
AnonymisationLeast privilege
Outcome
An indirect prompt-injection path was identified and closed using context minimisation. The assistant's tool permissions were also restricted so that a compromised interaction could not reach payment functions.
Key learning
Retrieved content is untrusted input. Protecting the model boundary is as important as protecting the network around it.
Challenge
An AI application was receiving complete patient records even though only a small number of fields were required for its task. This increased both privacy exposure and the potential impact of a security incident.
Controls applied
AnonymisationEncryptionAccess
Outcome
Sensitive fields were masked and context was minimised at the application boundary. The most sensitive workloads also adopted additional protection during processing.
Key learning
The safest data is the data an AI system never sees. Minimisation reduces both breach exposure and compliance scope.
Challenge
A retailer deployed an agentic assistant that could take actions on customer accounts. Permissions had been granted broadly during initial deployment to make integration easier.
Controls applied
Least privilegeRole-based accessKey management
Outcome
Tool permissions were reduced to the minimum required. High-impact actions were placed behind confirmation controls, while model credentials received usage and spend limits.
Key learning
AI agents inherit the reach they are given. Least privilege needs to be designed into the system before deployment.
Challenge
A SaaS platform had embedded model API keys in application code without automated rotation or usage limits. A leaked credential could therefore have resulted in both unauthorised model access and uncontrolled costs.
Controls applied
Key managementLeast privilege
Outcome
Model credentials were moved into a managed secret store with rotation, separation of duties and per-key spend limits.
Key learning
Model credentials are production secrets. They can create both a cybersecurity risk and a direct financial attack surface.
Disclaimer: illustrative use cases based on anonymised real-world scenarios.
06 · Questions leaders ask
AI Data Security Q&A
Continue through the stack
Related Layers
Security protects the data this layer makes traceable and trustworthy. Strong AI data security depends on knowing what data exists, where it came from and how it is being used.
L04 · where this feedsModel testing & assurance →Red teaming and model testing probe many of the same weaknesses this layer is designed to defend against, including prompt injection, sensitive-data leakage and excessive agency.
Next step
Next Step — Is Your AI Defended Against AI-Native Attacks?
Book an AI security review: a structured session that benchmarks your data, model and agent security against the five controls in this layer.
The review can examine encryption, anonymisation, AI access controls, least privilege and key management, alongside AI-native risks such as prompt injection, excessive agency, credential exposure and tool poisoning.
Why T3
Why T3 for AI Data Security & Access Controls?
T3 is an award-winning AI implementation partner for high-risk industries.
We support the adoption of trustworthy AI across the entire lifecycle. We design and engineer bespoke AI security controls, conduct adversarial red teaming on models and AI systems, and implement end-to-end AI governance operating models.
Our approach aligns AI security with recognised frameworks and standards, including the EU AI Act, ISO/IEC 42001, and NIST AI RMF.
Where off-the-shelf GRC platforms stop, we build the custom controls, integrations and assurance that fit your technology stack, models, data and regulatory environment.
Trusted by two-thirds of BigTech and Financial Services, this is where policy meets engineering.
