Cybersecurity for the AI Enterprise: Securing Models, Agents and Identity

New York AI Forum™ Intelligence | Cybersecurity

Enterprise AI is creating a new security boundary. Models now sit inside search, coding, customer service, research, analytics and decision workflows. Agents can go further by calling tools, accessing systems and taking actions. Security therefore has to protect not only the model, but also the identities, permissions, data paths, tools and decisions surrounding it.

Technical note: NIST’s Cyber AI Profile remained in development in 2026. References below distinguish preliminary or workshop material from final standards.

01 AI security is broader than model security

A narrow security program asks whether the model can be attacked. An enterprise program asks what the AI system can reach, what it can expose, what it can change and how the organization will know when something goes wrong.

The attack surface includes prompts, retrieval sources, model APIs, training or fine-tuning data, credentials, plugins, agent tools, software supply chains, logging systems and human workflows. A weakness anywhere in that chain can become an AI security incident.

02 NIST’s 2026 work frames three connected problems

NIST’s preliminary Cyber AI Profile organizes the problem around three focus areas: securing AI system components, conducting AI-enabled cyber defense and thwarting AI-enabled cyber attacks. Workshop reports published in August 2026 also highlighted governance, AI attack surfaces, taxonomy, risk-based guidance and AI-enabled defense opportunities.

This enterprise framing recognizes AI simultaneously as a system to secure, a defensive capability and a capability available to attackers.

03 Identity becomes the control plane for agents

Agentic AI makes identity architecture central. An agent should have a persistent or traceable identity, defined authority, short-lived credentials where appropriate, least-privilege access and revocation mechanisms. It should not inherit broad human credentials simply because a user initiated the workflow.

Organizations also need to distinguish the human principal from the agent principal. Logs should make it possible to reconstruct who initiated an action, which agent executed it, which tool was used, what data was accessed and whether an approval step occurred.

04 Tool access needs explicit boundaries

An AI system that can draft an email has a different risk profile from one that can send it. The same distinction applies to querying a database versus changing records, producing code versus deploying it, or recommending a transaction versus executing it.

Permissions should therefore be designed around action classes, transaction limits, environment boundaries and approval thresholds. Sensitive actions may require deterministic checks or human authorization outside the model’s own reasoning loop.

05 Prompt injection is an authorization problem as much as a content problem

Prompt injection can cause an AI system to follow malicious instructions embedded in user input, documents, webpages or tool outputs. Filters can help, but the deeper defense is architectural: an untrusted instruction should not be able to grant itself authority.

Systems should separate data from instructions where possible, constrain available tools, validate outputs before execution, enforce permissions independently of the model and treat retrieved content as potentially hostile.

06 Data protection needs context-aware controls

AI systems can create new routes for sensitive data to leave its intended context. Risks include accidental prompt disclosure, over-broad retrieval, logging of sensitive content, model-provider retention, insecure embeddings, misconfigured connectors and excessive agent permissions.

Enterprises should map data classes to approved AI environments, enforce access at the source, minimize unnecessary retention and ensure that retrieval respects the same permissions that apply to the underlying system of record.

07 Supply-chain risk expands with AI dependencies

Production AI often depends on multiple external layers: foundation models, open-source components, vector databases, orchestration frameworks, APIs, plugins, data providers and cloud infrastructure. Each layer adds operational and security dependency.

Third-party review should consider data handling, security practices, incident notification, model or service change policies, subcontractors, availability, export or jurisdictional considerations, and the organization’s ability to replace a provider if required.

08 Logging must capture AI actions, not just application events

Traditional logs may show that an API was called without explaining the AI decision path that produced the call. For material systems, organizations may need additional context: model and version, prompt or instruction class, retrieved sources, tools selected, policy checks, approvals, output, execution result and relevant errors.

The objective is not unlimited retention of every prompt. It is sufficient evidence to investigate incidents, validate controls and reconstruct consequential actions while respecting privacy and data-minimization requirements.

09 AI can strengthen cyber defense—but needs its own controls

AI can help summarize alerts, accelerate investigation, support threat hunting, generate detection logic, classify vulnerabilities and improve analyst workflows. These uses can increase defensive capacity, especially where security teams face high information volume.

But cyber-defense AI should still be evaluated for false positives, hallucinations, adversarial manipulation, data leakage and automation risk. The more authority a defensive agent receives, the more carefully its actions should be bounded and monitored.

10 A practical enterprise control model

Security leaders can organize AI controls around six questions: What AI assets exist? What identities and permissions do they use? What data can they access? What tools or actions can they invoke? What evidence is logged? What is the incident and recovery path?

Those questions connect cybersecurity to AI governance and enterprise architecture. They also create a common language across security, platform, data, risk and business teams.

11 The security objective is controlled autonomy

Enterprises will continue increasing the autonomy of AI systems where it creates value. The security goal should not be to prevent autonomy outright. It should be to make autonomy bounded, observable and reversible.

That means authority is explicit, credentials are scoped, high-impact actions have gates, systems can be disabled quickly, and evidence exists to reconstruct what happened. In the agentic enterprise, trust is not a feeling about model quality. It is an engineered property of the surrounding system.

Sources & notes

• NIST IR 8596, Preliminary Draft Cyber AI Profile, December 2025; 2026 working-session updates.
• NIST IR 8607, Cyber AI Profile Workshop #2 Summary, August 2026.
• NIST IR 8578, Cyber AI Profile Workshop #1 Summary, August 2026.
• NIST Cybersecurity Framework 2.0 Quick-Start Guides.