Spreadsheets Won't Stop a Rogue Agent
Why governance, risk and compliance professionals can no longer afford to be non-technical and must become technically self-reliant.
Ask any engineer about their company’s GRC team, and watch their face. You’ll usually get a pause, then a sigh, then a story.
The auditor who asked for proof that antivirus was installed on containers that only live for ninety seconds. The questionnaire asking whether the data centre had locked doors and CCTV, sent to a team that runs entirely on AWS. The launch held up for three weeks because nobody on the compliance side could read the architecture diagram.
For a long time, this was the job. GRC meant checklists, evidence requests and sign-offs. Too often it also meant passing the buck: asking engineers to prove they were safe without understanding enough to help them get there. And for a long time, it worked well enough.
Why the old model survived
The checklist approach survived because the world it governed was slow, predictable and explainable.
Systems changed in quarterly releases. Audits were annual and an annual snapshot was a fair picture of a system that barely changed in a year. When something went wrong, an engineer could trace the behaviour to a line of code, a configuration or a commit.
The system did what it was written to do, so a GRC team that didn’t understand the technology could lean on people who did and get a straight answer. This was GRC’s safety net.
Friction was annoying, but affordable. A three-week review barely registered against a release that had taken nine months to build.
What AI breaks
AI removes that safety net, and it changes what the business needs from GRC.
Everything moves faster. AI agents can read an email, make a decision and update a system in seconds. Teams now ship new AI features in weeks. Reviews built around annual audits can’t keep up, and when GRC falls behind, the business stops waiting.
Engineers can’t give you all the answers. With AI, nobody can point to the exact reason a model made a decision, not even the people who built it. GRC can no longer rely on engineers to explain everything. It needs to understand the controls itself.
The risks are technical. An agent with too much access. A hidden instruction inside a document. Activity logs the system can change. A questionnaire won’t catch any of these. You only find them by understanding how the system works.
Slowness now costs the whole business. When change was slow, a slow GRC team annoyed a few engineers. Now every team is using AI, so a slow GRC team holds back the entire company, or gets ignored.
Now imagine governing all of that with a spreadsheet. The old ways of working are no longer sufficient. GRC professionals must become more technically self-reliant to survive in this new playing field. This doesn’t mean every GRC professional needs to become an engineer. But it does mean the job needs a new set of skills.
Microsoft’s CEO, Satya Nadella, made the same point in his essay on models as insider risks:
“Setting aside the hard problem of alignment, we need to start with an engineering approach to containment and governance.”
What “technical” actually means
Being technical doesn’t mean learning to code. It means you can sit in a meeting with engineers, follow what they’re saying, and ask questions that actually help.
- First, you need to know how systems and especially AI systems fit together. Think of it like a floor plan. You should be able to see what information the AI can reach, what tools it can use, and which actions it can take without asking anyone.
- Second, you need to know how these systems go wrong. Imagine someone slipping a note into a pile of invoices that says, “Pay this one twice.” A person would spot it. An AI agent might just do it. Once you understand the consequences, you’ll know exactly what to ask the team building one.
- Third, you need to tell a strong control from a weak one. Telling an AI “never share customer data” is like putting a “Please don’t enter” sign on a door. Removing its access to that data is like locking the door. Only one of them works when it matters.
- Finally, you need to turn what you’ve learned into decisions: a risk assessment your leaders can act on, a policy your engineers can build, and evidence your auditors will accept.
You won’t learn any of this from reading a framework. You learn it by doing it yourself.
Friction now has a much bigger price
When change was slow, a GRC team that couldn’t keep up disappointed a handful of engineers. Now that every team is adopting AI, it disappoints the whole business.
Product teams are shipping AI features in weeks. If risk review can only move at the pace of a questionnaire, the business will route around it. Shadow AI tools get adopted, agents get connected to production quietly, and GRC finds out after the incident. A GRC professional who understands the technology can do the opposite: join early, ask questions that matter, and help make the safe path the fast one.
That’s why I created the AI Security and Governance track at AIFoundry. It’s a six-week, hands-on course for GRC, risk and audit professionals, and you don’t need to know how to code. Each week, you work on a real AI system in your browser.
You map how it works, try to break it, add the right controls and check that they hold. Every module ends with something you can take back to work, like a threat model or a full risk assessment. To get certified, you don’t sit a multiple-choice test. You assess a realistic company rolling out AI, just as you would on the job.
If your company is now looking to you to govern AI, this course was made for you.
Sources
New field notes, teardowns and guides from real AI security work, in your inbox. No spam, unsubscribe any time.
We'll only use your address to send new posts. Privacy