You Use AI at Work. That Already Makes You a Security Stakeholder.

Mon, 11 May 2026 00:00:00 +0000

The Part No One Mentions When They Hand You an AI Tool

When an organization rolls out an AI tool to its workforce, the conversation usually goes one direction: productivity. Here is what it can do. Here is how to use it. Here is the prompt template.

Nobody hands you an AI tool and says: here is the security architecture surrounding every session you will have with this system. Here is the data pipeline your conversations flow through. Here is what happens if that pipeline is compromised, misconfigured, or deliberately manipulated.

I spent time going through the Securiti AI Security and Governance Certification — eight modules covering AI risk management, data and AI relationships, security controls for LLM systems, and global regulatory compliance. What I walked away with was not primarily a framework vocabulary. It was a shift in perception. Every AI tool I use at work now looks different to me than it did before. Not more threatening, exactly — more visible. I can see the security infrastructure that surrounds it, and more importantly, I can see where that infrastructure is absent.

That shift in perception is what this post is about.

Shadow AI Is Already in the Room

Most people think of shadow AI as a rogue-employee problem. Someone downloads an unauthorized chatbot, pastes in company data, and security has a headache. That version of the story is real, but it is the least interesting one.

The more common version is quieter. Your approved SaaS platforms — the tools your IT and procurement teams signed off on — are adding AI features as standard upgrades. A productivity suite adds AI summarization. A customer support platform adds AI-generated response suggestions. An HRIS system adds AI-assisted performance analytics. These features are often enabled by default. The vendor agreement your organization signed may or may not address what happens to the data those features process.

This is the model discovery problem, and it is the foundation of any serious AI governance conversation. You cannot govern what you cannot see. More immediately for the individual worker: you cannot make informed decisions about what data to share with a tool if you do not know what the tool is doing with it.

Your prompts are data. Your conversation history is data. The documents you upload for summarization are data. Where that data goes — whether it is retained, whether it is used for model training, whether it is accessible to the vendor, whether it is encrypted in transit and at rest — determines the real risk profile of that tool. Not its feature list.

Shadow AI is not just the tools your organization has not approved. It is the AI pipelines embedded in the tools they have approved, operating in ways nobody fully audited.

Every Prompt Has an Attack Surface

There is a common assumption that AI security is about protecting the model from the outside. The model is the defended thing. The user is behind the perimeter.

That assumption is wrong, and the OWASP Top 10 for Large Language Models makes it concrete.

Prompt injection is the clearest example of why. A direct prompt injection is straightforward: a malicious user tries to override the model’s instructions by crafting adversarial input. But indirect prompt injection is different — and more relevant to ordinary workers. An indirect injection happens when an attacker embeds malicious instructions inside a document, webpage, or data source that the AI will later retrieve and process. The model reads the poisoned content and follows the embedded instructions. The user who triggered the retrieval had no idea it was happening. You can be the vehicle for an attack without ever making a malicious choice.

Sensitive data leakage is the second failure mode that every user creates exposure for. Models are trained on data. They are prompted with context. Both of those data sources can surface unexpectedly in model outputs. An AI assistant given access to organizational data stores can, under the right conditions, return information that was never intended to appear in a user-facing response. This is not a theoretical vulnerability — it is documented in production systems.

Excessive agency is what happens when AI systems are granted broad permissions to act autonomously. An AI agent that can send emails, create calendar events, modify records, or execute code has a correspondingly large attack surface. The capabilities that make it useful are the same capabilities that make a compromised or manipulated session dangerous. Every permission granted to an AI agent is a permission that can be invoked by an attacker who successfully manipulates the session.

The common thread across all of these: the AI tool is not just a tool. It is a system with inputs, outputs, retrieval pipelines, permission sets, and trust boundaries — all of which are exploitable if they are not explicitly defended. Organizations running production LLM systems without layered firewall controls — prompt, retrieval, and response — are operating with a gap between those boundaries and enforcement.

The Frameworks That Define the Rules You Are Already Playing By

The frameworks that govern enterprise AI are not written for compliance officers. They describe the risk landscape that every AI user is operating in, whether they know it or not.

The NIST AI Risk Management Framework defines risk as a function of two variables: the magnitude of harm that would result from an AI failure, and the likelihood of that failure occurring. Multiply them and you have a risk score. Every AI tool in your organization already has such a score — it just may not be formal or documented. The NIST framework is the structure that makes it formal. When security and governance teams are assessing which AI systems need the most rigorous controls, they are applying this logic. The tools in your daily workflow are part of that calculation.

Gartner’s AI TRiSM — AI Trust, Risk, and Security Management — identifies four pillars that a trustworthy AI system must satisfy: explainability and model monitoring (can you understand and track what the model is doing?), model operations (is the model managed throughout its lifecycle?), AI application security (is the model protected against attacks?), and model privacy (does the model handle data consistently with privacy requirements?). These pillars map directly to questions an individual worker should be asking about the tools they use. Not as a formal audit, but as a baseline of awareness.

The EU AI Act takes a more prescriptive approach. It classifies AI systems by risk tier, and some of the highest-risk categories are firmly in the enterprise space: AI used in hiring decisions, employee performance assessment, credit scoring, medical diagnostics, and law enforcement. If your organization uses AI to support any of these functions, those systems are subject to significant regulatory obligations before deployment — conformity assessments, documentation requirements, human oversight mechanisms, and registration in an EU database. Non-compliance carries fines of up to fifteen million euros or three percent of global annual turnover.

That is not an abstract consequence. For workers in HRIS, finance, healthcare, or recruiting who are integrating AI tools into core workflows, this regulatory reality is immediate and specific.

Security Is Not Just IT’s Problem Anymore

The certification I went through made a lot of things clearer, but one thing most clearly: AI governance is not a compliance team function that gets handed down as a policy. It is a shared responsibility that extends to everyone who interacts with AI systems at work.

That is not a burden. It is a change in the nature of what it means to be an informed professional in an AI-integrated workplace.

Security decisions used to happen at the perimeter — at the firewall, at the access control list, at the endpoint protection layer. The individual worker was largely downstream of those decisions. AI changes that. Every prompt is a decision about what data leaves your organization’s control. Every AI-assisted task is a point of potential exposure. Every AI agent given permission to act on your behalf is a trust extension that carries real consequences.

I do not think this means everyone needs to become a security engineer. It means that understanding the landscape matters — knowing what shadow AI is, what prompt injection looks like, what the frameworks mean when they say high-risk, what LLM firewalls do and why they exist. That baseline of literacy is what separates an AI user who is an informed participant in their organization’s security posture from one who is an uninformed risk.

The tools are powerful. The productivity gains are real. The security infrastructure that makes those gains sustainable is also real — and understanding it is not optional for organizations that want to keep using AI responsibly.

If you use AI at work, you are already inside this system. The only question is whether you understand the landscape you are operating in.