When I review an AI deployment, I rarely start with the model. I start with the identity using it.
Who created it? What can it access? What decisions can it make? Where does the data go? Can we see what it did after the fact?
These are basic security questions, but they are where control is often lost.
Most companies already have more AI than their official inventory shows. Employees use tools such as Claude, Cursor, Microsoft Copilot, and Glean. Developers call models through APIs. Engineering teams build agents in cloud environments. Existing SaaS platforms add AI features, connectors, service identities, and automated workflows.
Every one of these creates a path between an identity, enterprise data, a model, and potentially another system. Securing that path requires more than approving the application. It starts with a strong identity foundation built on Zero Trust.
Least privilege is no longer enough
Least privilege answers one question: What can this identity access?
With AI agents, we need to go further. I use the term least agency to describe the minimum authority an AI system needs to complete a specific task.
That includes the data it can retrieve, the tools it can use, the decisions it can make, the actions it can take, and how long that authority should remain active.
A coding assistant may need to read selected repositories. It should not automatically inherit production credentials. A customer-service agent may retrieve an account, but that does not mean it should issue a refund, change payment information, or disable the account.
That may require just-in-time access, short-lived credentials, transaction limits, human approval, or a firm separation between recommending an action and executing it.
This is how we give AI room to be useful without giving it open-ended authority.
“The more consequential the action, the stronger the control should be.”
Inventory identities, not just products
A list of approved AI vendors is a procurement inventory. It is not a security inventory.
An enterprise AI inventory should include every identity participating in the transaction:
Employees using AI applications
Service accounts calling model APIs
Workload identities used by agent runtimes
OAuth applications, connectors, plug-ins, and MCP servers
Agents created by employees
Agents created automatically by platforms or other agents
Models and external providers receiving prompts, files, or retrieved context
Each identity needs an owner, business purpose, authentication method, approved data scope, permission boundary, operating environment, model provider, logging destination, review date, and expiration condition.
Auto-provisioning deserves particular attention. An approved platform may create sessions, child agents, temporary credentials, or new tool connections. Short-lived identities are still identities. If they can access data or take action, they must be visible and governed.
The lifecycle should be clear from request through removal: approval, provisioning, operation, permission changes, review, suspension, and decommissioning. If the owner leaves, the project ends, or the purpose changes, the access should not continue by default.
Follow the data through the entire transaction
Identity tells us who can act. Data flow tells us what is at risk.
For each AI use case, we should be able to trace:
Human or workload → application or agent → enterprise system → retrieved data → model → model provider → output → downstream action
That transaction may cross several security boundaries.
Glean may retrieve internal company knowledge. Cursor may access source code and invoke a model operated by another provider. An agent running in AWS or Azure may query a database, call a SaaS API, send selected context to a model, and write the response into another business system.
We need to know exactly what data was retrieved, what entered the prompt, which model processed it, where processing occurred, how long the provider retains it, whether it can be used for training, and what the output was allowed to do.
A policy telling employees not to paste confidential information into AI will not solve this. Approved data paths need to be enforced through classification, DLP, connector restrictions, egress controls, encryption, provider settings, and contractual requirements.
Govern productivity tools and agent runtimes together
Enterprise AI commonly grows along two tracks.
The first is workforce productivity through tools such as Claude, Copilot, Cursor, and Glean. The practical controls include SSO, MFA, automated provisioning and deprovisioning, approved enterprise tenants, DLP, browser and endpoint visibility, connector governance, retention settings, and centralized audit logs.
The second is agentic runtime infrastructure: cloud-hosted models, agent frameworks, APIs, vector stores, tool gateways, and automated workflows. These environments require workload identity, managed secrets, private connectivity, hardened execution, tool allowlists, runtime monitoring, and authorization at the point of action.
These should not become separate governance programs. The same framework should cover identities, data, models, tools, actions, providers, and evidence across both.
A system prompt is not a security boundary
Effective guardrails operate in layers:
Identity controls determine who can invoke the AI.
Authorization controls limit available data and tools.
Model controls inspect unsafe inputs and outputs.
Runtime controls restrict network access, code execution, and transactions.
Human controls govern sensitive or irreversible actions.
Monitoring controls detect misuse, drift, abnormal cost, and unexpected behavior.
“Prompt-level instructions are useful, but they are not access controls.”
None of this works well without sound cloud foundations. Centralized identity, segmented environments, private endpoints, managed secrets, policy-as-code, complete logging, and tested incident response remain essential.
AI does not make those fundamentals obsolete. It makes weaknesses in them move faster.
Visibility is the real outcome
Before approving an AI use case, security leaders should be able to answer five questions:
What AI systems and agents are operating?
Who owns them?
What identities, data, models, and tools can they access?
What actions can they take, and under whose authority?
Can we reconstruct what happened?
The answers should come from systems and logs, not presentation slides.
When that visibility exists, governance becomes useful. Risk can be measured, controls can be tested, incidents can be investigated, and teams can adopt AI without creating authority they cannot see or control.
Secure AI begins with identity. It matures through least agency, lifecycle governance, traceable data flows, layered guardrails, and disciplined cloud foundations. The model may receive most of the attention, but the system surrounding it determines whether enterprise AI remains secure and accountable.
“AI does not make those fundamentals obsolete. It makes weaknesses in them move faster.”