Layer 03 · AI governance
AI Security & Access
Protect the data, and the model, from misuse, leakage, and attack.
Classic data security still matters: encryption, access control, key management. But AI adds a new attack surface that firewalls never anticipated: prompts that hijack instructions, outputs treated as trusted, and agents with more reach than anyone intended. This layer covers both. Five controls protect data at rest, in transit, and in use, and extend to the AI-native threats that turn a helpful model into an open door.
Active defence
Access controlled, data protected, keys held
AI widens the attack surface: new data flows, new credentials, new ways in. This layer encrypts what matters, scopes who can reach it, and keeps every key and privilege accounted for.
*Illustrative figures for a representative estate.
01 · Where it begins
AI Security & Access Challenges
AI security is more than protecting a database. Five questions decide whether your models and their data are defended against both classic and AI-native attacks. Each points to a control in this layer.
02 · The controls, explained
The five controls that secure AI
Each control is a distinct capability with a clear definition, a working mechanism, where the field is heading, and the consequence of skipping it. Each is also extended here to the AI-native threats that traditional security controls were never designed for.
Encryption
Protecting data at rest, in transit, and in use.
Definition
The practice of rendering data unreadable to anyone without the right key, not only when it is stored and transmitted, but increasingly while it is being processed by a model.
How it works
Data is encrypted at rest and in transit as standard. The frontier is encryption in use: confidential computing and secure enclaves that keep model inputs and outputs protected even during inference, so sensitive prompts and responses are not exposed in memory to the platform running them.
How we help
We review where your AI data is exposed across its lifecycle, close the gaps at rest and in transit, and advise on confidential-computing options for the highest-sensitivity workloads, so protection follows the data into the model, not just around it.
Without it
Sensitive prompts, documents, and model outputs sit readable in storage, in transit, or in memory. A single breach exposes not just a database but the intellectual property and personal data flowing through every AI interaction.
Latest advancement
2025–26Confidential computing reaches AI inference. Secure enclaves are increasingly used to protect prompts and responses during processing, extending encryption to the one place AI data used to be exposed: while the model is actually using it.
Anonymisation
Ensuring models see only what they need.
Definition
The practice of removing or masking personal and sensitive information before it reaches a model or prompt, through de-identification, differential privacy, and context minimisation, so exposure is reduced by default.
How it works
Sensitive fields are masked or tokenised at the boundary, privacy-preserving techniques limit what can be inferred from aggregated data, and context minimisation ensures a model is sent only the information a task genuinely requires, not an entire record because it was convenient.
How we help
We design masking and minimisation into your data and prompt pipelines, so personal data is stripped or reduced before it reaches a model, shrinking both your breach exposure and your regulatory surface at the same time.
Without it
Models and their logs accumulate personal data they never needed, every one a liability. Sensitive information ends up in prompts, caches, and third-party systems, expanding the blast radius of any leak and the scope of any audit.
Latest advancement
2025Context minimisation becomes a security control. As prompt-injection and data-leakage risks grow, sending a model the minimum necessary context is treated not just as privacy hygiene but as a way to limit what an attacker can ever extract.
Role-based access
Controlling who, and what, can reach models and data.
Definition
The practice of granting access to datasets, models, and tools based on defined roles, extended, in the age of AI, to the non-human actors: the agents and services that now request access on their own.
How it works
Access is tied to roles rather than individuals, and every AI agent or service is given its own identity and permission set. That makes it possible to say precisely which humans and which machines can reach a given model, dataset, or tool, and to revoke it in one place. (This assumes a unified IAM architecture; in practice, many organisations manage this across several systems.)
How we help
We design role-based access that treats agents as first-class identities, define the permission model for human and machine actors alike, and make access reviewable and revocable, so an agent’s reach is a deliberate decision, not an inherited default.
Without it
Access sprawls. Agents run with whatever credentials they were first handed, people retain access long after they need it, and no one can answer the basic security question: who and what can reach this model and its data?
Latest advancement
2025–26Non-human identity goes mainstream. As autonomous agents proliferate, managing machine identities and their permissions is becoming as important as managing human ones, and the fastest-growing gap in most access-control models. Zero Trust architectures, dedicated agent identity management, and just-in-time access, granting elevated permissions only for the duration a task requires, are current enterprise practice for closing that gap.
Least privilege
Minimising the blast radius, and the risk of excessive agency.
Definition
The principle of granting every actor the minimum access needed to do its job, and, for autonomous agents, constraining the scope of tools it can reach so a single compromised or mistaken action cannot cascade.
How it works
Permissions are scoped tightly and reviewed regularly. For agents, this means limiting tool-access scope and gating high-impact actions: the direct antidote to excessive agency, where a model is given more autonomy, permissions, or functionality than its task warrants and can take consequential actions no one intended.
How we help
We map what each system and agent can actually reach, strip back the excess, and design action-gating so high-impact operations require confirmation, shrinking the blast radius of any failure, attack, or hallucinated decision.
Without it
An over-privileged agent that is jailbroken, misconfigured, or simply wrong can move money, delete data, or contact customers at scale. Excessive agency turns a contained incident into an organisation-wide one.
Latest advancement
2025Excessive agency named a top LLM risk. The OWASP Top 10 for LLM Applications lists excessive agency (LLM06) among the leading risks for AI applications, making least privilege and tool-scope limits a core control for any agentic system, not an optional hardening step.
Key management
Governing the secrets that protect everything else.
Definition
The practice of generating, storing, rotating, and retiring the cryptographic keys and secrets that underpin every other security control, because encryption and access control are only as strong as the keys behind them.
How it works
Keys are held in HSM-backed key management systems (KMS) and dedicated secrets managers, rotated on a schedule, and governed by separation of duties so no single person or system holds end-to-end control. API keys and model credentials, increasingly the target of attacks aimed at running up cost or exfiltrating data, are treated with the same rigour.
How we help
We review how your keys and AI credentials are stored, rotated, and separated, close the gaps, and bring model and API secrets under the same managed regime as the rest of your cryptographic material.
Without it
A leaked key unravels every control it protects. Hard-coded API credentials, unrotated secrets, and shared keys are among the simplest and most common ways an AI system is compromised or an attacker runs up an uncapped bill.
Latest advancement
2025–26Model credentials become a prime target. As API-based models carry real cost and data access, securing and rotating model credentials, and capping their spend, is now a first-order concern alongside traditional key management. Crypto-agility and post-quantum readiness are emerging as the next best practice, so keys can be migrated to quantum-resistant algorithms without re-architecting the systems that depend on them.
Threat coverage
AI-native threats × the controls that meet them
Which controls mitigate which AI-native threats, and how strongly. Darker cells mean stronger coverage; the light ones are where residual risk lives.
03 · A practical reference
AI-native threats and the controls that meet them
Firewalls and encryption do not stop a prompt-based attack. These are the risks specific to AI applications, drawn from the OWASP Top 10 for LLM Applications, and the controls in this framework that mitigate them.
| Risk | What it is | Primary mitigations |
|---|---|---|
| Prompt injection LLM01 | Malicious instructions in user input or retrieved content hijack the model | Privilege separation, human approval for consequential actions, input validation and context minimisation |
| Sensitive-info disclosure LLM02 | The model reveals personal data, secrets, or system prompts | Anonymisation, least privilege, output filtering |
| Supply-chain risk LLM03 | Compromised models, datasets, or dependencies | Provenance, registry, dependency review |
| Data poisoning LLM04 | Training or fine-tuning data is tampered with to corrupt model behaviour | Data provenance, dataset validation, anomaly detection |
| Improper output handling LLM05 | Model output is trusted and executed without checks | Treat output as untrusted; validate before use |
| Excessive agency LLM06 | An agent has more autonomy or reach than its task needs | Least privilege, tool-scope limits, action gating |
| Prompt leakage LLM07 | System prompts or instructions are extracted and exposed | Secrets kept out of prompts, output filtering, least privilege |
| Vector & embedding attacks LLM08 | Retrieval or embedding stores are manipulated or mined for sensitive data | Access control on vector stores, anonymisation, encryption |
| Unbounded consumption LLM10 | Denial-of-service or “denial-of-wallet” via runaway usage | Rate limits, spend caps, key management |
Treat model output as untrusted input. The most common AI security failures come from trusting what a model produces: executing its code, following its instructions, or rendering its text without checks. A model can be manipulated through its inputs, so its outputs must be validated before they trigger any action, exactly as you would validate input from an anonymous user.
03b · Standards mapping
Where each control satisfies a recognised obligation
AI security draws on both established information-security standards and AI-specific guidance. Each control maps to the references your auditors and security teams already use.
| 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 but not sufficient for AI. A credible AI-security posture adds the following on top of the fundamentals.
- Defence against prompt injection. Inputs, including retrieved and third-party content, are validated, and system instructions are protected from override.
- Untrusted output handling. Model output is validated before it is executed, rendered, or used to trigger an action.
- Agent identity and scope. Every agent has its own identity, least-privilege permissions, and limited tool-access scope.
- Action gating. High-impact operations require confirmation rather than executing autonomously.
- Consumption limits. Rate limits and spend caps guard against model denial-of-service and denial-of-wallet.
- Encryption in use. The most sensitive workloads protect prompts and outputs even during processing.
From the white paper
When AI stops responding and starts acting, errors are no longer outputs. They become actions.
That is why guardrails stop being constraints and become architecture. Least privilege stops being hygiene and becomes the blast-radius control for every agent you deploy.
“Guardrails are enablers, not constraints”, T3
Failure modes
How access control fails for AI
Where AI widens the attack surface faster than controls keep up.
The over-privileged agent
One agent with access to everything; a single compromise reaches every system.
Fix · Least privilege plus tool and permission scoping, per agent.Title-based access
A product manager on credit can reach the mortgage and AML models because their role allows it.
Fix · Attribute-based access control: identity, device, location and context evaluated in real time.No kill switch
No tested way to halt an agent mid-action.
Fix · Fail-safe and recovery: kill-switch, rollback and safe fallback, tested before launch.Guardrails bolted on later
Treated as a post-deployment fix.
Fix · Guardrails as deployment architecture, tracked via incidents, false positives and trust scores.*Illustrative failure patterns, not client-specific incidents. Trust scores are composite ratings of guardrail reliability, based on incident rate and false positives, increasingly paired with Zero Trust architectures and Just-in-Time access as current enterprise practice.
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 scenarios
AI security is not abstract. Each scenario shows a genuine challenge, the controls that addressed it, and the outcome, anonymised across regulated industries.
Challenge
A retail bank’s customer assistant pulled from internal knowledge articles, and no one had tested whether hostile content in those documents could redirect the model.
Controls applied
AnonymisationLeast privilege
Outcome
An indirect prompt-injection path was found and closed with context minimisation under anonymisation, and the assistant’s tool access was scoped under least privilege so a hijack could not reach payment functions.
Key learning
Retrieved content is untrusted input. Securing the model boundary matters as much as securing the network around it.
Challenge
A health provider’s AI tools were being sent full patient records when only a handful of fields were needed, expanding both breach and compliance exposure.
Controls applied
AnonymisationEncryptionAccess
Outcome
Masking and context minimisation at the boundary cut the personal data reaching models to the minimum, and encryption in use was adopted for the most sensitive workloads.
Key learning
The safest data is the data a model never sees. Minimisation shrank the breach blast radius and the audit scope in one move.
Challenge
A retailer deployed an agentic assistant that could take actions on customer accounts, but its permissions had been granted broadly to get it working.
Controls applied
Least privilegeRole-based accessKey management
Outcome
Tool-access scope was cut to the minimum, high-impact actions were gated behind confirmation, and spend caps were placed on the model credentials, containing excessive agency before it caused an incident.
Key learning
Agents inherit whatever reach they are first handed. Least privilege has to be designed in, because it is rarely granted by default.
Challenge
A SaaS platform embedded model API keys in application code, with no rotation and no cap: a single leak from running up an unbounded bill.
Controls applied
Key managementLeast privilege
Outcome
Model credentials were moved to a managed key store with rotation, separation of duties, and per-key spend limits, removing both the exfiltration and the denial-of-wallet risk.
Key learning
Model credentials are as sensitive as any production secret, and now carry a direct financial attack surface that classic key management must extend to cover.
Disclaimer: illustrative use cases based on anonymised real-world scenarios.
06 · Questions leaders ask
AI security Q&A
Continue through the stack
Related layers
Next step
Is your AI defended against AI-native attacks?
Book an AI security review: a structured session that benchmarks your data and model security against the five controls in this layer, including prompt injection, excessive agency, and credential exposure. You keep the findings either way.
Book a review →Why T3
Why T3 for Security & Access for AI?
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 controls, conduct adversarial red teaming on models and AI systems, and implement end-to-end AI governance operating models, aligned to standards we helped write such as 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 stack, your models, and your regulator.
Trusted by two-thirds of BigTech and Financial Services, this is where policy meets engineering.
