What guardrails or security considerations do you put into place while you are vibecoding and/or bake into your AI agents?
I think this is a great question. How can you add guardrails or security considerations? Is it something you could use in a prompt when creating a task, i.e. “using NIST 800.171” or some other regulation?
I have a lot of thoughts here, so forgive the lengthy post. I’ve broken this into 3 sections: HOW I build, WHAT I build, and WHERE NIST comes into play.
How I incorporate security considerations into my development processes:
I have tools that review my code for security holes before committing it. Every meaningful change goes through a structured security review - checking for the most common ways that software gets compromised. This is all based on industry security standards (OWASP Top 10 most critical web application security risks, and OWASP web security testing guide which is a more detailed testing methodology). Fortunately, my organization provides me with these tools.
When I use automated tooling to scan for vulnerabilities, these tools run in a sandbox environment that has no internet access, can’t write into my system, and can’t escalate their own permissions.
Every time I push code, automated code checks look for known vulnerable libraries, committed secrets (tokens / passwords), and static code issues.
Speaking of secrets, I make it a practice to keep passwords, API tokens, and credentials as environment variables - never in the code itself. But there’s the scanner mentioned above that provides a safety net just in case.
I have rules in place that makes sure my AI code assistant answers these questions before it deletes anything: What’s the backup plan? Can this be undone? And the tool has to prompt me for verification prior to deleting anything. No deletes without my permission, ever. This is less about security than resiliency, but still an important point.
Another rule I have in place is that my databases, debug logs, security scan reports, and other sensitive files never get committed to my GitHub / GitLab repositories.
And my GitHub / GitLab repositories are locked down by default. I have to invite people to see them or contribute to them.
Security features in the tools themselves:
Everything that my AI tools do requires a human to confirm it first. Before an agent adds a block of text to a file, sends an email, changes a calendar invite, writes to long-term memory, etc., it has to show me what it’s about to do and get an explicit yes. It won’t go off and do something that has real-world consequences on its own. For example, an agent can draft an email but only I can send it.
The dashboards I’ve built for my own use “live” on my machine, so others can’t read it. It’s a web UI but just for me. I can export and share with individuals with a need-to-know.
I’ve hardcoded a rule that once a week the tool scans its own codebase and the libraries it depends on to see if there are any known security issues since the last check, and there is a noticeable banner that pops up if there is something I need to take care of.
Every single change to the data is logged. There’s a record of what changed, when, and how. This means I can trace something back to the root of a problem if needed.
Systems are separated so one agent can’t write data for another system. For example, my calendar data doesn’t overwrite my task list.
Sensitive data can be used “in the moment” with explicit permissions from me, but that sensitive data is never written into files that live in version control.
Where NIST controls come into play:
That’s the governance and process layer - the confirmation gates, audit logging, least-privilege data handling, access controls, etc.
When I first start building something new, I write a rule that the tool must be built with security best practices in mind, like NIST 800-53. Periodically throughout development I’ll ask the AI code assistant to tell me how it is building with security best practices in mind, review what it has done, and recommend fixes in case anything has gone off the rails. I keep it “accountable”.
Continuing on the topic of security…
How are you actually training your org’s users on AI security and prompt hygiene?
Most enterprise AI rollouts I’ve seen follow the same arc: leadership greenlights a tool, IT provisioning happens fast, and then someone quietly realizes that employees are casually pasting customer data, internal financials, or unreleased product specs directly into prompts — with zero awareness that this might be a problem.
The security and governance piece of AI adoption is usually treated as a legal/IT checkbox. But the practitioners in this community know it’s much more than that. It’s a behavior change problem, and behavior change is hard.
A few things I keep running into that I’d love to hear how others are handling:
1. Getting users to actually internalize prompt hygiene
It’s one thing to tell people “don’t put PII or proprietary information in your prompts.” It’s another to make that instinct automatic — especially when the whole value proposition of AI is that you can just talk to it naturally.
What frameworks have you seen actually stick? I’ve been thinking about something like a “public newspaper test”: before you hit send, ask yourself — if this prompt showed up on the front page of a trade publication, would you be embarrassed? Simple, but it creates a pause that most policy docs don’t.
2. The difference between tool-specific risk and general AI literacy
A user working in a copilot embedded in your internal ITSM tool has different risk exposure than someone with direct access to a frontier model API. Most training materials I’ve seen treat these the same, which means neither group gets what they actually need.
How are you thinking about segmenting training by role and access level? Has anyone built tiered AI literacy programs that actually account for this?
3. Governance theater vs. governance that works
Usage policies read by no one. AI acceptable use agreements that are 14 pages of legalese. We’ve all seen it.
What does real AI governance look like at the practitioner level — the stuff that actually changes behavior rather than just creating audit artifacts? I’m especially curious about organizations that have moved beyond the “first wave” compliance framing and are treating this as an ongoing capability-building problem.
4. The prompt quality gap
This one doesn’t get talked about enough alongside security: most employees who have access to AI tools are getting maybe 20% of the possible value because they don’t know how to prompt well. Bad prompts = frustrated users = “AI doesn’t work for me” = shadow IT or abandonment.
What’s your approach to upskilling users on prompt craft without it feeling like another mandatory training module?
I’ll share what I’ve been building on this front in a follow-up, but I want to hear from this community first. What’s working? What’s a waste of time? And where are organizations most dangerously underprepared?
Tagged: Prompt Engineering #enterprise-ai #governance #security #ai-training #human-readiness
1 Like