Cybersecurity on

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.

This post draws on material from the Securiti AI Security and Governance Certification, the NIST AI Risk Management Framework, the OWASP Top 10 for Large Language Models, and Gartner’s AI TRiSM framework.

AI Writes Code Fast. Here's Why Security-First Thinking Matters More Than Ever.

Sun, 19 Apr 2026 00:00:00 +0000

Speed Is the Feature. Unexamined Speed Is the Liability.

One of the most impressive things about using AI to write code is how fast it moves. You describe an endpoint, a data model, a feature — and within seconds you have working code. Not a sketch. Not pseudocode. Actual, runnable implementation.

That speed is real, and it is genuinely useful. I use it every day.

But here is something I noticed the longer I worked with AI-generated code: it writes to the happy path. AI is extraordinarily good at making code that works when everything goes as expected. It is considerably less reliable at writing code that stays safe when things go wrong — when someone sends unexpected input, when a dependency is compromised, when a secret accidentally surfaces in a log, when a logged-in user tries to access someone else’s data.

This is not a criticism of AI models. It is a structural observation about how code generation works. AI learns from what code looks like, not from what happens to systems that run it. The attack surface is invisible at generation time.

Security-first thinking is the discipline that fills that gap. And building it into how you work with AI is one of the highest-leverage things you can do as a developer.

What AI Gets Wrong By Default

Before we get to principles, it helps to see the failure modes concretely. These are patterns I started noticing after reviewing AI-generated code more carefully.

Hardcoded secrets. Ask AI to write a function that connects to a database or calls an external API, and it will often produce something like this:

db = connect(host="prod-db.company.com", user="admin", password="Sup3rS3cr3t!")
client = OpenAI(api_key="sk-proj-abc123...")

The code works. It will also put your credentials in git history forever. A secret committed to a repository — even briefly, even to a private repo — must be treated as compromised. Git history is permanent. The only remediation is rotation.

Missing input validation. AI tends to write code that trusts request data. An endpoint that receives req.body.quantity will often use it directly, skipping the check for whether it is a positive integer, whether it is within expected bounds, whether it contains what the code assumes it contains.

Fetch-then-check authorization. This one is subtle. AI commonly writes authorization logic like this:

const order = await db.orders.findById(req.params.id);
if (order.userId !== req.user.id) return res.status(403).send();
return res.json(order);

That looks right. But it fetches the record first and checks ownership second. A slightly better pattern is to include the user ID in the query itself, so that non-owned records simply return null — and you return a 404, not a 403. Returning 403 confirms to an attacker that the resource exists. It is a small thing that compounds at scale.

Weak cryptography by familiarity. Ask AI to hash a password and it might reach for SHA-256. SHA-256 is a solid hash function — for data integrity. It is the wrong tool for passwords because it is fast. Fast means a GPU can test billions of candidate passwords per second against a leaked hash. bcrypt and Argon2 are deliberately slow. That slowness is the security property.

No rate limiting on authentication. AI generates login endpoints without the defensive scaffolding that should always accompany them: rate limiting per IP, account lockout after repeated failures, uniform response times to prevent user enumeration.

None of these are exotic edge cases. They are the everyday failure modes that show up in security audits and breach post-mortems, again and again.

The Mindset Shift: From Checklist to First Principles

Here is where I want to push back against the usual framing. Security is often presented as a checklist — OWASP Top 10, compliance requirements, “use HTTPS.” Checklists have their place, but they do not produce secure code. They produce code that passes the checklist.

Security-first thinking is different. It is a way of looking at code that asks one question at every boundary: who or what is being trusted here, and has that trust been earned?

Every class of vulnerability — SQL injection, XSS, CSRF, IDOR, broken authentication, insecure deserialization — reduces to a single failure: untrusted data crossing a trust boundary with the authority of trusted data.

SQL injection happens when user input is trusted to be SQL-safe before it reaches the database. XSS happens when user-generated content is trusted to be display-safe before it enters the DOM. IDOR happens when a request parameter is trusted to represent a resource the current user is allowed to access.

Once you see security through this lens — trust boundaries and their enforcement — you stop asking “did I remember the checklist item?” and start asking “where are the trust boundaries in this code, and what enforces them?” That question applies to every system, every language, every framework. It does not go stale.

This is what I mean by security-first thinking as a mindset rather than a procedure. It is not about knowing rules. It is about developing the habit of seeing trust assumptions in code.

The Eight Principles

When I worked through this with Luna recently — building a security knowledge base from 50 cybersecurity books — we distilled the trust boundary framework down to eight irreducible properties that AI-generated code must satisfy.

I want to walk through each one because they are not independent rules. They are facets of the same underlying principle.

1. Input is untrusted by default. Every value arriving from outside your process — HTTP body, query parameters, headers, cookies, file uploads — is hostile until validated. Client-side validation is UX. Server-side validation is security. They cannot substitute for each other.

2. Output is encoded for its context. A string displayed in HTML needs HTML encoding. A value interpolated into SQL needs parameterization. A value passed to a shell command needs to go through an argument array, not string concatenation. The encoding is not about the string itself — it is about the context it will be interpreted in.

3. Secrets never live in code. Passwords, API keys, tokens, certificates — these belong in environment variables or a secrets manager, never in source files. This is absolute. Git history is permanent.

4. Authentication is verified, not assumed. Every protected route, every protected function, checks identity on that request. Being logged in at some prior point does not carry forward.

5. Authorization is checked at the data layer. Being authenticated is not the same as being authorized to access a specific resource. Ownership checks belong in the query itself, not as a post-fetch condition.

6. Least privilege is the default. Database connections, service accounts, IAM roles, file operations — each gets only the access its specific function requires. Nothing more. A compromised least-privilege component fails safely. A compromised over-privileged one does not.

7. Cryptography is never homegrown. Cipher and hash choices go to battle-tested libraries: bcrypt or Argon2 for passwords, AES-GCM for encryption, HMAC-SHA256 for message authentication. The failure modes of hand-rolled crypto are subtle and catastrophic.

8. Dependencies are trust extensions. Every package you add is code you are trusting. Its transitive dependencies are code you are trusting. Supply chain attacks are real. Lock files, audits, and version pinning are not paranoia — they are basic hygiene.

These eight properties are not a checklist to run through at the end. They are filters to apply while generating code. The question during every code-writing session is: which of these are relevant to what I am building right now?

Baking It Into Your AI Workflow

Knowing principles is not the same as applying them consistently. The reason I started building infrastructure around this is that consistency requires more than intention — it requires systems.

Here is what I built, and it came directly from the work of turning 50 cybersecurity books into a searchable knowledge base.

Tier 1 topic files. Each of the eight principles above now lives in a concise reference file — 8 to 12KB each — distilled from the source material. input-validation.md, secrets-management.md, authentication.md, authorization.md, cryptography.md, and the others. Each file is dense but scannable: concrete patterns, code examples, anti-patterns, quick checklists.

Engineer PREFERENCES. I wired those topic files into the Engineer agent through a PREFERENCES file. The trigger table maps code categories to topic files: anything involving SQL gets xss-injection-prevention.md loaded. Anything involving authentication loads authentication.md. Anything involving secrets loads secrets-management.md. The agent loads the relevant files silently before writing code and runs the associated checklist before declaring work done.

The result is that security context is present in every relevant code-generation session without me having to ask for it. The principles are not something I have to remember to invoke. They are part of the workflow infrastructure.

This is what I keep coming back to with PAI: the value is not in any single AI interaction. It is in building infrastructure that makes the right thing the default thing. Security-first code used to require conscious effort and specialized knowledge in the moment. Now it is loaded context — always present, reliably applied.

Security and AI Are Not in Tension

I want to end on this because it is easy to come away from a security conversation feeling like the message is “AI is dangerous, slow down, be careful.” That is not the message.

AI writing code fast is a genuine capability improvement. Being able to go from specification to working implementation in minutes changes what is possible for a small team or a solo developer. That is real.

Security-first thinking is not a constraint on that capability. It is the thing that makes the output of that capability trustworthy. Code that moves fast and ships vulnerable systems is not actually faster in any meaningful sense — it is accumulating debt that will be paid with interest.

The combination is the point. AI that knows how to think about trust boundaries, that loads security context automatically, that applies principles rather than just patterns — that is a force multiplier, not a liability. You get the speed and you get the rigor.

Building toward that combination is one of the more interesting engineering problems I have worked on. The knowledge base, the topic files, the wiring into the workflow — it is all aimed at the same thing: making security-first thinking something that happens automatically, not something that requires a specialist in the room.

The specialist knowledge exists. We built it into 77KB of reference material drawn from 50 books. Now it is always in the room.

Part of the PAI series on building infrastructure that makes AI more useful, more reliable, and more trustworthy. The security knowledge base and topic files referenced in this post were built using Claude Code, PostgreSQL, pgvector, and source material from O’Reilly’s security catalog.

I Turned 50 Cybersecurity Books Into a Searchable Brain

Sat, 21 Mar 2026 00:00:00 +0000

The Problem With Security Books

I have a lot of cybersecurity books. PDFs from Humble Bundles, O’Reilly downloads, books I’ve bought and never finished, reference material I collected “just in case.” Like most people, they lived in a folder I rarely opened.

The reason is friction. When I needed to look something up — say, how SQL injection payloads work, or the steps for privilege escalation on Linux — I’d have to remember which book covered it, open it, and search inside. Or just Google it and hope Stack Overflow had something decent.

That’s not a knowledge base. That’s a graveyard.

So I built something better: a local semantic search engine over all of them, powered by PostgreSQL, pgvector, and OpenAI embeddings. Now I ask questions in plain English and get back the exact passages — with the book and chapter — that answer them. The whole thing runs locally on my machine.

Here’s how I built it, and why it’s become one of the most useful tools in my PAI (Personal AI Infrastructure) stack.

What Semantic Search Actually Means

Traditional search is keyword matching. You type “SQL injection” and it finds documents containing those exact words.

Semantic search is different. It converts your query and your documents into vectors — lists of numbers that represent meaning in high-dimensional space. Similar concepts cluster together regardless of exact wording. Ask “how to bypass database input validation” and you’ll surface the same SQL injection content, even though you never typed “SQL injection.”

This matters enormously for a security knowledge base. Security concepts have dozens of names. “Privilege escalation,” “privesc,” “root access,” “vertical privilege abuse” — these all mean the same thing. Semantic search finds all of them.

The Stack

PostgreSQL 17 — the database
pgvector 0.8.2 — vector similarity search extension for Postgres
OpenAI text-embedding-3-small — converts text chunks to 1536-dimensional vectors
CyberSecKB.ts — a custom Bun/TypeScript CLI I built to tie it all together

Everything runs locally. The only external call is to OpenAI’s embedding API (which runs once at ingest time, not at query time).

The Pipeline: From PDF to Searchable Knowledge

Step 1: Convert PDFs to Markdown

Raw PDFs are terrible for text processing. I convert everything to Markdown first using a pdf2md Python tool:

cd ~/projects/pdf-to-markdown
source venv/bin/activate

# Text-based PDFs (most books):
python pdf2md input/mybook.pdf

# Image-based or scanned PDFs (use OCR first):
ocrmypdf --force-ocr input/mybook.pdf /tmp/ocr.pdf
python pdf2md /tmp/ocr.pdf output/mybook.md

# Move to library:
mv output/mybook.md ~/projects/cybersecurity-library/books/

Step 2: Ingest into the Database

TOOL=~/.claude/skills/PAI/USER/KNOWLEDGE/CYBERSECURITY/Tools/CyberSecKB.ts

# Single book with topics tagged:
bun $TOOL ingest \
 --file ~/projects/cybersecurity-library/books/mybook.md \
 --title "My Book Title" \
 --topics web,network,linux

# Or load everything at once:
bun $TOOL ingest --batch ~/projects/cybersecurity-library/books/

The ingest process:

Reads the Markdown file
Splits it into ~800-token chunks, preserving chapter headings
Sends chunks to OpenAI’s embedding API in batches
Stores chunks + their vector embeddings in PostgreSQL

Step 3: Search

# Plain English query:
bun $TOOL search "how do attackers bypass WAF rules for SQL injection"

# Filter by topic:
bun $TOOL search "privilege escalation" --topics linux --limit 5

# Check what's in the KB:
bun $TOOL list
bun $TOOL stats

What It Looks Like in Practice

Here’s a real query. I asked:

bun $TOOL search "SQL injection bypass techniques" --limit 3

Result:

━━━ [63.3%] Web Penetration Testing With Kali Linux → Detecting and Exploiting Injection-Based Flaws
The `;` metacharacter in a SQL statement is used similarly to how it's used
in command injection to combine multiple queries on the same line...
━━━ [62.5%] Web Penetration Testing With Kali Linux → Detecting and Exploiting Injection-Based Flaws
If user input is used without prior validation, and it is concatenated
directly into a SQL query, a user can inject different data...
━━━ [60.4%] Web Penetration Testing With Kali Linux → Detecting and Exploiting Injection-Based Flaws
Input taken from cookies, input forms, and URL variables is used to build
SQL statements that are passed back to the database...

Each result shows the similarity score, book title, chapter, and a preview. I can immediately tell which book to go deeper in.

Another query — privilege escalation:

bun $TOOL search "privilege escalation linux" --limit 3

━━━ [66.1%] Cybersecurity Attack And Defense Strategies → Privilege Escalation
Most systems are built using the least privilege concept — users are
purposefully given the least privileges they need to perform their work...
━━━ [65.9%] Kali Linux Cookbook → Privilege Escalation
CVE-2015-1328: overlayfs vulnerability affecting Ubuntu where it does not
do proper checking of file creation in the upper filesystem area...
━━━ [65.8%] Cybersecurity Attack And Defense Strategies → Privilege Escalation
On Linux, vertical escalation allows attackers to have root privileges
that enable them to modify systems and programs...

This is the power of the system: I asked about a concept, not a keyword, and got specific, sourced, actionable results from three different books.

The Current State of the KB

After the initial batch ingest:

50 books indexed
11,757 chunks stored and embedded
Coverage spans: penetration testing, malware analysis, forensics, identity and access, cloud security, social engineering, cryptography, threat modeling, and more

Some of what’s in there:

Practical Malware Analysis (620 chunks)
Cybersecurity Threats, Malware Trends and Strategies (552 chunks)
Cybersecurity Attack and Defense Strategies (460 chunks)
Security Chaos Engineering (387 chunks)
Hardware Hacking Handbook (378 chunks)
Modern Data Protection (338 chunks)

Why This Fits Into PAI

This knowledge base is part of my PAI system — Personal AI Infrastructure. The idea behind PAI is to build infrastructure that amplifies what I can do with AI, rather than using AI one prompt at a time.

The Security KB is a perfect example. It’s not about asking ChatGPT “explain SQL injection.” It’s about having my own curated library, chunked, embedded, and ready to surface exactly the passage I need — from books I trust, with sources I can trace back.

When I’m working through a security challenge or studying for a certification, I can query the KB directly. Luna (my PAI assistant) can also query it as part of a larger workflow — search the KB, pull context into the prompt, and answer questions grounded in my actual library rather than generic training data.

Building It With Claude Code

The entire CyberSecKB tool was built using Claude Code through PAI. The process:

Described what I wanted: ingest markdown books, chunk by section, embed with OpenAI, store in pgvector
Claude Code scaffolded the TypeScript CLI
We hit a few real-world issues along the way:
- The OpenAI project key needed embedding model access enabled separately
- Batch size of 2048 hit the 300k token/request limit — tuned down to 200
- The 1M tokens/minute rate limit required adding a 15-second delay between batches
- A SQL type error in the search function when no topics filter was passed

Each issue was diagnosed and fixed in the same conversation. The tool went from concept to 50 books indexed in a single session.

What’s Next

A few things I want to add:

Tag all books with proper topics — the batch ingest skipped topic assignment; I’ll tag each book so --topics web or --topics linux filters actually work
Tier 1 topic files — condensed 5-15KB reference files for the most-used topics (SQLi, XSS, privilege escalation, etc.) that load directly into context
AI Security KB integration — the AI Security research KB shares the same database; queries cross both domains automatically

The knowledge base is live. The friction is gone. Now the books actually get used.

Built with PAI, Claude Code, PostgreSQL, pgvector, and OpenAI embeddings. All processing runs locally except the embedding API calls at ingest time.