The security of an AI-powered system is decided during the design phase, or it isn't decided at all: what's added at the end are partial mitigations of decisions already made. A guardrail that filters responses doesn't fix a poorly designed permissions model, just as a railing doesn't correct the foundations.
The difference between the two ways of working isn't one of security. It's one of cost, and it's enormous: what a two-hour conversation costs before starting can cost an entire project later.
Decision | If taken at the beginning | If you try to add it later |
|---|---|---|
What identity does the system use to access it? | Configuration | Redo integrations and permissions model |
What actions can you perform? | List closed from the start | Audit and limit code already in production |
What is recorded for each execution | Instrumentation from day one | The past cannot be reconstructed |
Separation of environments | Project structure | Migration at risk of disruption |
Where they reside and who processes the data | Choice of architecture | Contract renegotiation and migration |
The third row has a property that makes it especially expensive: It is irreversible.. If it wasn't registered, it doesn't exist. When a client, an auditor, or a court asks what the system did three months ago, the answer won't depend on a willingness to cooperate, but on a technical decision someone made—or didn't make—before starting.
It's important to be precise, because this article could be interpreted as disparaging guardrails, which it isn't. Filtering inappropriate content, detecting known manipulation patterns, and limiting response length are all useful measures.
What they fail to do is contain structural damage. A guardrail acts on the text that enters and leaves; it doesn't act on what the system can do. If the system has permission to process a payment, no content filter prevents that payment from being processed when something causes the system to decide to do so.
The correct hierarchy is this:
Order matters. Starting with point 4 is the usual thing to do because that's what you can buy; starting with 1 is what works because that's what you design.
These are the questions we ask ourselves before writing code in any project with AI components:
With what identity does the system access each source? The correct answer is almost always: with the user's, propagated.
What is the closed list of actions that can be performed? Listed, not described. What is not listed does not exist.
Which actions are irreversible and who validates them? Payments, external communications, production changes, and anything that affects third-party data.
What is recorded, where, and for how long? With enough detail to reconstruct a specific case months later.
What data enters the system and what data is excluded by explicit decision? The "just in case you need it" is the origin of most exhibitions.
How do you stop it and how do you reverse it? A mechanism that does not require deploying code or depending on the provider.
Six questions, one meeting. It's the intervention with the best cost-benefit ratio of the entire project, and it's the one that's skipped the most because during the week everyone wants to see something working.
The opposing argument is always the same and it's reasonable: there's pressure to show results and security slows things down.
The useful response is not to appeal to abstract risk, but to offer a concrete alternative: a smaller reach with the complete design. In other words, not to reduce security to meet the deadline, but to reduce the functional scope and keep the six decisions intact.
A system that does three things well, with limited permissions and traceability, can be expanded. A system that does thirty things without control has to be rebuilt before it can be expanded, and by then there are already users depending on it.
Haste is not the enemy of safety. Scope is.
It's about making security decisions—access identity, permitted actions, logging, environment separation, and data residency—during the design phase, not after construction. These decisions are inexpensive to make initially but very costly to modify once the system is in production.
To filter inappropriate content, detect known manipulation patterns, and limit response formats. What they don't do is contain structural damage: they act on incoming and outgoing text, not on what the system can execute with its granted permissions.
Six: with what identity does the system access each source, what is the closed list of allowed actions, what actions are irreversible and who validates them, what is recorded and for how long, what data is excluded by explicit decision, and how is the system stopped and reversed.
Because it's irreversible: if it wasn't recorded, the information doesn't exist. When a client, auditor, or court asks what the system did months ago, the ability to answer will depend on a technical decision made before it even began.
The NIST AI RMF structures risk management on the ability to identify, measure, and control; ISO/IEC 42001 requires evidence of ongoing control for certification; and the European AI Regulation mandates event logging, technical documentation, and demonstrable human oversight for certain categories.
Reducing the functional scope, not the design decisions. A system that does three things well with limited permissions and traceability can be expanded; one that does thirty without control must be redesigned before expanding, especially when users are already depending on it.
Are you going to start an AI project? The two-hour conversation about identity, permissions, actions, and registration is the most worthwhile investment in the entire project. We'll do it with you, no strings attached. Let's talk → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
