TL;DR: Enterprise AI security now depends on protecting data in use, verifying environments with attestation, and tying key release to proof before AI workloads touch sensitive data, according to Fortanix; the article argues that traditional encryption and scattered governance leave AI inference, agents, and auditability exposed.
At a glance
What this is: This is a guide to enterprise AI security that argues production AI needs in-use protection, attestation, and governed agent activity, not just conventional encryption.
Why it matters: It matters because IAM, PAM, and AI governance teams must treat AI agents, keys, and audit evidence as part of the control plane for sensitive workloads.
By the numbers:
- 93% of AI leaders know that traditional encryption does not protect data while it is processed in memory, according to Fortanix.
Context
Enterprise AI security is the governance gap that opens when models, prompts, keys, and agents move into production faster than the control model around them. Traditional encryption protects data at rest and in transit, but AI workloads process sensitive material in memory, where ordinary perimeter and storage controls do not fully apply.
That gap becomes more serious when agentic systems can call tools and take actions across business systems without human approval. In practice, this is not just an AI architecture problem, because the controls that matter most are identity, privilege, key release, logging, and auditability, which is why AI agent identity security becomes relevant once agents are given real authority.
Key questions
Q: What should teams do before moving AI workloads into production?
A: Teams should define separate access controls for model serving, GPU provisioning, and supporting infrastructure before production rollout. They should also verify that logging, ownership, and approval paths stay visible across the full deployment chain. Without that, production AI work can outgrow the controls meant to govern it.
Q: Why do traditional encryption controls fall short for enterprise AI?
A: Because encryption usually protects data at rest and in transit, while AI systems process data in memory. During inference, models, prompts, and sensitive inputs may be exposed to privileged runtime actors unless the workload is isolated and attested. That is why in-use protection is now a governance requirement, not just a technical enhancement.
Q: What happens when an AI agent is allowed to act without per-action approval and audit?
A: The session can move from low-risk work to irreversible change in seconds. If the agent finds an unexpected credential or follows a compromised instruction, it may delete production data, expose regulated information, or use the wrong token for a broader operation than intended. Without approval and an auditable decision trail, the organisation cannot explain who authorised the action or why it was allowed.
Q: Should organisations prioritise attestation or access control for AI systems?
A: They should treat them as linked controls, but attestation comes first when the goal is to protect sensitive in-use data. Access control decides who may request action, while attestation decides whether the environment is trustworthy enough to receive keys and datasets. Without proof of environment integrity, access control alone is incomplete.
Technical breakdown
Why data in use creates a different security boundary
AI inference and training change the risk model because data, prompts, and model weights are decrypted, or otherwise available, while computation happens. That means a compromised hypervisor, privileged administrator, or malicious runtime actor can potentially see information that conventional encryption would normally hide. The core issue is not that encryption failed, but that the protection boundary must move from storage to execution. Trusted execution environments and attestation are designed to narrow that gap by proving where the workload is running and under what conditions. See the AI Security Posture Management (AI-SPM) Guide.
Practical implication: Treat in-use protection and attestation as prerequisites for sensitive AI workloads, not optional hardening.
How attestation and key release work together
Attestation is the proof step. It verifies that hardware and software match expected integrity conditions before secrets are released. If the attestation chain is strong, key management systems can gate access to encryption keys, datasets, and model weights until the workload is trusted. That creates a policy boundary where unverified systems do not get the material they need to process sensitive data. The value is in coupling trust verification to cryptographic release, because isolated controls leave gaps that attackers or misconfigured systems can exploit.
Practical implication: Bind key release to successful attestation so unverified environments cannot process protected AI data.
Why agentic AI behaves like a privileged identity problem
Agentic AI is not just a model integration issue. Once a system can plan, invoke tools, and act across business systems, it starts to resemble a privileged identity that needs explicit scope, separation of duties, and approvals. The article’s point is that most identity and key management tooling was not built with AI agents as first-class identities. That creates a governance gap around what an agent may access, modify, or automate, and it makes post-incident reconstruction harder when logs are fragmented across tools and platforms. See the AI Agent Identity Security Buyer's Guide.
Practical implication: Model AI agents as governed identities with narrow scope, approvals for sensitive actions, and centralized logs.
Threat narrative
Attacker objective: Access sensitive systems, internal code, and protected AI data by exploiting weak trust assumptions around AI execution and agent authority.
- Entry occurs when a researcher or attacker interacts with an AI chatbot or agent surface that exposes internal capability or workflow trust.
- Credential access follows when the actor reaches sensitive systems, internal code, or runtime material that should have remained behind stronger trust boundaries.
- Escalation happens when the actor or malicious agent uses available privileges, tool access, or unverified execution paths to expand reach.
- Impact is exposure of private systems, internal code, or sensitive data, with incident response complicated by fragmented logging and weak in-use controls.
Breaches seen in the wild
- McKinsey AI platform breach: McKinsey AI platform hack exposed 46M chats and sensitive data.
- DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Enterprise AI security is becoming an identity and key governance problem, not just a model protection problem. The article is right to separate storage encryption from in-use protection, because AI workloads expose data in memory where normal safeguards no longer hold. That shifts the control question to who or what can gain access, under what proof, and with what audit trail. Practitioners should treat AI runtime authority as part of the identity model, not as a separate technical layer.
Data in use is the new control boundary for sensitive AI workloads. The article shows why conventional encryption is insufficient once prompts, weights, and data are processed inside the runtime. That is the same governance pattern seen in other high-trust systems: the risk is not theft at rest, but exposure during execution. This is where attestation and conditional key release become decisive, because they control whether a workload is allowed to function at all.
Agentic AI creates a first-class privileged identity challenge. When an agent can call tools and take actions across business systems, the security model needs explicit scope, approvals, and revocation. The article correctly notes that scattered logs make reconstruction slow after an incident, which means governance has to happen before action, not after the fact. Agentic AI security policy is the right abstraction when agents move from experimentation into operational authority.
The market is moving toward verifiable AI rather than assumed trust. The five practices in the article point to a control stack built around proof, scope, and audit, not optimism about vendor assurances. That aligns with broader AI governance expectations in frameworks such as NIST AI RMF and EU AI Act readiness. For practitioners, the practical conclusion is simple: if you cannot prove the environment, the keys, and the agent’s authority, you do not yet have production-grade AI governance.
Named concept: in-use trust gap. This article captures the gap between encrypted storage and unprotected execution, where data becomes visible to runtime actors even when the organisation thinks it is protected. The issue is not a missing firewall or a single misconfiguration, but a trust boundary that ends too early. Practitioners should design AI controls around this gap rather than around storage-only assumptions.
From our research library:
- Enterprise AI use rose from 55% of organisations in 2023 to 88% in 2025, according to McKinsey’s Global Surveys on the State of AI.
- Read next: AI Security Posture Management (AI-SPM) Guide
What this signals
In-use trust gap: enterprise AI programmes now need a control model that proves the runtime is trustworthy before sensitive data is ever decrypted there. That shifts governance from perimeter defence to environment proof, key gating, and continuous evidence generation. Teams that cannot produce this proof will struggle to defend sensitive inference use cases at scale.
AI agents should be governed as privileged identities with explicit scope, approvals for high-risk actions, and unified logging across toolchains. The operational challenge is no longer whether a model can answer a question, but whether an autonomous action can be authorised, traced, and revoked with confidence.
The practical signal for security teams is that AI governance and IAM are converging. As agents and workloads take on more authority, programme owners will need to decide which systems are allowed to release keys, which actions require quorum, and which evidence satisfies audit and compliance requirements.
For practitioners
- Protect sensitive AI workloads in trusted execution environments Run training and inference for sensitive data inside hardware-based trusted execution environments so prompts, weights, and data remain protected during processing.
- Bind key release to attestation evidence Require successful attestation before releasing encryption keys, model weights, or datasets, and block unverified environments from starting sensitive workloads.
- Treat AI agents as privileged identities Define what each agent may access, modify, and automate, then apply least privilege, separation of duties, and quorum approval for sensitive actions.
- Centralise audit trails for all AI activity Send model, agent, and platform logs into one immutable audit trail so security, compliance, and incident response teams can reconstruct actions quickly.
- Start with lower-sensitivity AI use cases Begin deployment with low-risk workloads while governance, evidence collection, and identity controls mature, then expand only after the control model is proven.
Key takeaways
- Enterprise AI security fails when organisations assume conventional encryption is enough to protect data that is being processed in memory.
- The article’s evidence points to a control gap between encrypted storage and trusted execution, which is where sensitive AI workloads are most exposed.
- Practitioners should gate keys on attestation, narrow agent authority, and centralise audit evidence before scaling production AI.
Related NHI Mgmt Group resources: AI Agent Identity Security Buyer's Guide · Agentic AI Security Policy Template · AI Security Posture Management (AI-SPM) Guide · AI Security Maturity Model
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agentic AI is central here because the article treats agents as privileged actors needing scope and approvals. |
| Recommendation — Apply ASI03 to scope agent authority, restrict sensitive actions, and review privilege boundaries before production use. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article is fundamentally about governance, accountability, and evidence for AI systems in production. |
| MANAGE — AI Risk Management | The article focuses on managing in-use risk, attestation, and control gaps in deployed AI systems. | |
| Recommendation — Establish governance, ownership, and evidence requirements before allowing sensitive AI workloads into production. Manage AI risk by tying runtime trust, key release, and logging to the controls that protect sensitive data. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article repeatedly centres on privileged access, least privilege, and approval boundaries for AI agents. |
| Recommendation — Use PR.AA-05 to limit what AI agents can access, modify, and automate in production systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Key gating and release based on attestation map directly to authenticator lifecycle governance. |
| Recommendation — Use IA-5 to govern secret release, rotation, and revocation for AI-related credentials and keys. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threat narrative involves privileged access to sensitive systems and expansion across business services. |
| Recommendation — Map AI runtime abuse to TA0006 and TA0008 when adversaries or agents expand access across systems. | ||
Key terms
- Data In Use: Data in use is information being actively accessed, processed, or modified by a user, application, or workload. It is the hardest state to govern because policy must follow live identity behaviour, not just storage location or network transit.
- Attestation: Attestation is verifiable evidence about a workload’s execution context, such as where it is running, who started it, and whether it matches policy. In agent governance, attestation can be used to bootstrap enrollment and to justify access decisions that need to change as the workload behaves differently.
- Trusted Execution Environment: A Trusted Execution Environment is a protected hardware-backed area where code runs with stronger isolation from the host system. In AI inference, the point is not just secrecy in transit, but limiting what operators, hypervisors, and surrounding infrastructure can observe during processing.
- Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect identity controls to the broader security programme as AI systems gain operational authority.
Published by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org