Download the AI-Readiness Checklist

AI Is Already Inside the Enterprise

Many organizations speak about artificial intelligence as if AI adoption is still a future technology initiative.

For most businesses, that is no longer accurate.

Employees are already using generative AI.

Developers are integrating models into applications.

Business teams are experimenting with copilots.

Organizations are connecting AI assistants to internal documents.

And increasingly, AI agents are being given access to applications, APIs and workflows.

The question facing security leaders is therefore shifting from:

“Should we allow AI?”

to:

“How do we control the AI already entering the organization?”

Simply writing an acceptable-use policy is not enough.

AI security has to become operational.

NIST’s AI Risk Management Framework and Generative AI Profile provide organizations with a structured way to think about AI risks, while OWASP continues to identify application-level risks affecting LLM and agentic environments.

The important step for enterprises is translating those principles into actual controls.

Here are seven places to start.


Control 1: Discover What AI Is Already Being Used

You cannot govern technology you cannot see.

An AI-security program should begin with an inventory of:

  • approved AI platforms
  • public generative AI services
  • AI-enabled SaaS applications
  • copilots
  • internally developed AI applications
  • foundation-model providers
  • APIs accessing AI services
  • retrieval-augmented generation systems
  • autonomous or semi-autonomous agents
  • AI-connected enterprise data sources

The inventory should also document business use cases.

Two employees using the same model may create very different levels of risk.

One may use AI to improve generic marketing text.

Another may upload confidential contracts, patient information, customer records or proprietary source code.

The technology may be identical.

The business exposure is not.

This is why AI discovery must extend beyond identifying the application itself.

Organizations need to understand:

Who is using it?

Why are they using it?

What information can it access?

What business process does it influence?

This creates the foundation for everything that follows.


Control 2: Establish Ownership and Governance

Every significant AI system should have an owner.

That sounds simple, but organizations frequently deploy AI capabilities without clearly identifying who is accountable for their security, data use and ongoing oversight.

Ownership should address:

  • business purpose
  • acceptable use
  • risk classification
  • data access
  • human oversight
  • change management
  • vendor responsibility
  • incident escalation
  • periodic review

AI governance should not become a committee that meets twice a year to review policies.

It should become part of the operating lifecycle.

The NIST AI RMF organizes AI risk management around Govern, Map, Measure and Manage. The broader lesson is important: governance needs to connect organizational policies with actual systems and actual risk decisions.

A policy saying “do not upload confidential data to AI” provides limited protection if the organization has no idea which AI platforms employees are accessing.

Governance and visibility have to work together.


Control 3: Apply Identity and Least Privilege to AI

Identity may become one of the most important controls in enterprise AI.

Consider a traditional chatbot.

Its capabilities may be limited to generating text.

Now consider an AI agent connected to:

  • Microsoft 365
  • Salesforce
  • ServiceNow
  • GitHub
  • cloud infrastructure
  • corporate databases
  • internal APIs

The security model changes substantially.

The agent may now be able to retrieve information or take actions.

Organizations must therefore answer:

Which identity is the agent using?

Whose authority is it operating under?

What permissions does it inherit?

What systems can it access?

Can it perform privileged actions?

Are credentials stored securely?

AI should follow the same principles organizations apply to human and machine identity:

  • least privilege
  • strong authentication
  • short-lived credentials where practical
  • privilege separation
  • lifecycle management
  • access reviews
  • logging
  • revocation

An AI agent should not receive broad administrative privileges simply because doing so makes integration easier.

Capability should be intentionally constrained.


Control 4: Define Data Boundaries

AI security is fundamentally connected to data security.

Organizations should clearly define which categories of information may and may not be submitted to different AI systems.

Examples might include:

Public information
Generally acceptable for approved AI services.

Internal information
May require approved enterprise AI platforms and contractual protections.

Confidential information
May require additional security architecture and data-handling restrictions.

Regulated or highly sensitive data
May require specific technical, contractual and compliance controls—or may be prohibited entirely depending on the environment.

Security teams should evaluate:

  • retention
  • model training practices
  • geographic processing
  • data sharing
  • encryption
  • tenant isolation
  • administrative access
  • deletion
  • logging
  • downstream integrations

The question should not simply be:

“Is this AI tool secure?”

The better question is:

“Is this AI tool appropriate for this particular data?”


Control 5: Control What AI Can Do—not Just What It Can See

This becomes especially important with agentic AI.

A traditional AI model primarily generates output.

An agent may generate output and execute actions.

That can include:

  • sending messages
  • creating tickets
  • querying databases
  • modifying files
  • running scripts
  • accessing cloud resources
  • invoking APIs
  • initiating workflows

OWASP’s recent work on generative and agentic AI highlights risks associated with excessive agency, identity and privilege abuse, tool misuse and AI supply-chain dependencies.

This means AI security architecture needs controls around actions, not simply prompts.

Depending on the use case, organizations may need:

  • allowlisted tools
  • explicit permission scopes
  • API restrictions
  • execution boundaries
  • transaction limits
  • human approval for high-risk actions
  • separation between read and write access
  • sandboxing
  • application control
  • network restrictions

The objective is to reduce the blast radius when an AI system behaves incorrectly—or is manipulated by an attacker.


Control 6: Log, Monitor and Maintain Human Oversight

AI systems should not become invisible autonomous infrastructure.

Organizations need sufficient logging to reconstruct:

  • which user initiated an interaction
  • which model or agent was involved
  • which tools were called
  • which data sources were accessed
  • which identity was used
  • what actions occurred
  • what security controls were triggered

That telemetry can eventually become part of broader security operations.

For high-impact workflows, human review remains important.

NIST’s ongoing Cyber AI Profile work has highlighted human-in-the-loop considerations as organizations integrate AI and cybersecurity.

Human oversight does not mean manually approving every AI response.

It means identifying situations where the consequences justify human judgment.

For example:

Drafting internal meeting notes: low consequence.

Automatically disabling an executive’s account: potentially high consequence.

The control should reflect the risk.


Control 7: Prepare for AI Incidents Before They Happen

Organizations already maintain incident-response plans for:

  • ransomware
  • compromised accounts
  • malware
  • data breaches

AI introduces additional scenarios.

What happens when:

  • sensitive data is submitted to an unauthorized AI platform?
  • an AI agent exposes credentials?
  • an employee installs a malicious AI browser extension?
  • an agent executes an unauthorized action?
  • an AI integration is compromised?
  • a model produces consequential false information?
  • a third-party AI provider experiences a breach?

Security teams should define:

How will the incident be detected?

Who owns containment?

Can tokens and credentials be revoked?

Can the AI integration be disabled quickly?

Are relevant logs available?

Which legal, privacy and compliance teams need notification?

AI security becomes substantially stronger when these questions are answered before an incident.


The Objective Is Not to Stop AI

Security programs sometimes respond to emerging technologies by attempting to prohibit them.

That approach rarely survives contact with business demand.

Employees will continue looking for productivity improvements.

Developers will continue integrating AI.

Executives will continue asking where AI can create competitive advantage.

The security objective should therefore be:

Enable useful AI while establishing defensible boundaries around data, identity and action.

That requires moving beyond a static AI policy toward an operating model.

A practical model might look like:

Discover → Map → Assess → Prioritize → Control → Monitor → Improve


Why AI Governance Must Connect to Security Operations

The long-term challenge is that AI environments continuously change.

Models change.

Permissions change.

New agents are created.

Data sources are connected.

APIs are added.

Business use cases evolve.

AI governance therefore cannot be a point-in-time project.

It needs an operational feedback loop.

This is where AI governance, IAM, Zero Trust, application security and security operations begin converging.

Security teams need to understand not merely whether an AI system was approved six months ago, but whether its current behavior and access remain appropriate today.


Start With Visibility

If your organization is building an AI-security program, begin with seven questions:

  1. Do we know which AI systems employees are using?
  2. Does every important AI system have an accountable owner?
  3. Do we know what identities and permissions AI systems use?
  4. Have we defined which data can be exposed to AI?
  5. Have we limited which actions AI agents can perform?
  6. Can we monitor AI activity?
  7. Do we have an incident-response process for AI-related events?

If several answers are “no,” you do not need to stop AI adoption.

You need to build the controls around it.


Secure AI Adoption Without Slowing Innovation

Velocis Technologies helps organizations build practical governance and security guardrails for generative and agentic AI.

Our approach connects:

AI governance + risk assessment + identity + Zero Trust + data protection + security monitoring + incident response

with recognized frameworks such as the NIST AI Risk Management Framework and ISO/IEC 42001.

The objective is not to create another policy document.

It is to create an operating model that helps organizations understand:

What their AI can access.

What their AI can do.

Who is accountable for it.

And what happens when something goes wrong.

Do you know where AI is already operating inside your organization?

Start with a Velocis AI Security & Governance Assessment.

→ Explore Velocis AI Security

Download the AI-Readiness Checklist

VT
AUTHOR

Velocis Technologies

Managed security operations and licensed investigations, based in Frisco, Texas.