Ask an executive what keeps their AI safe, and you get a list. A policy the model is told to follow. A review board that signs off before launch. A security team that owns the perimeter and the passwords. All of it is real, all of it in place, and none of it necessarily holding the model at the moment it decides.
Hold that against how AI runs. The model does not read your policy in the moment and choose to comply. It applies what it inherited, at machine speed, and a rule it can ignore is not a rule. It can reach past what it was meant to touch faster than a separate function can weigh in, and the control that could stop it may answer to someone other than the seat running the model.
This is not a fringe concern. More than a hundred companies, among them OpenAI, Anthropic, Google, Microsoft, and the major security firms, put their names to an open letter warning that the security practices most organizations run today will not hold as AI-enabled attacks grow more capable. The letter named the threat in detail: hospitals, water systems, the infrastructure that carries the internet. What it could not name, because no letter can, is the seat inside your organization that holds the line when the model is pushed past its bounds.
And the model does not only get pushed from outside. An attacker steering it past its limits and the model drifting past them on its own start from different causes, but they arrive at the same place: a system acting outside what it was authorized to do. The letter is the loud version of a problem that runs quietly every day. Both meet the same answer. A boundary that holds, and a seat that owns it.
That is the work of the middle block of GSC. GSC stands for Governance, Security, and Control, the eight-mechanism control structure the conn holds. The conn is the named human accountable for a running AI system, the one seat that reads the model and can act on it. This is the Security block, and it is two live mechanisms, guardrails and security. The block shares its name with one of its mechanisms, so hold the two apart as we go. Governance keeps the model honest against the operating design you intended. The Security block is what constrains the model when honest is not enough. It is the brake, not the bureaucracy.
One word on terms. When we say the running model, we mean the live AI system: its model, its data, its tools and workflow, the decisions it makes, and the human handoffs around it in production. Not only the underlying model. The whole system as it runs.
One. Guardrails, the limit on what the model can do
A guardrail can exist only as an instruction. A line in a prompt. A clause in a policy. A note in the onboarding deck that says the model must not do a certain thing. An instruction depends on the model, or the person, choosing to honor it. And it is found to be missing only after the model has already crossed it.
As a GSC mechanism, a guardrail is a boundary enforced in the flow of the work, not a request the system is trusted to respect. When the model reaches the limit, the limit acts, in the moment, without waiting for anyone to notice. No control is perfect, and a guardrail is not a promise the model can never be pushed past. It is the difference between a boundary that holds on its own and a rule that holds only when someone is watching.
The conn owns those boundaries, and not by hovering over a kill switch. The seat sets the limits in advance, tightens them when the model drifts toward an edge, and holds the authority to add one the day a new edge appears. The enforcement runs at machine speed because the conn’s decisions are already encoded into it. The seat is the accountable owner of the boundaries, not a pair of hands on every transaction. A guardrail you can talk your way around is a suggestion. A guardrail is what holds when talking stops.
Two. Security, the control over what the model can reach
Guardrails constrain what the model can do. Security constrains what the model can reach: the access and identity controls that decide which systems, tools, and data the model and its agents can touch, and the standing power to narrow or revoke that access when it should not hold.
Access control is capable. Continuous verification and dynamic access decisions can track who and what reaches the model and adjusts as it runs. The gap is not capability. It is connection. Where those controls are not wired to the seat accountable for the running model, the capability to catch a drifting reach exists while the authority to act on it sits elsewhere. An agent granted access for one task begins to use it for another, or a workflow picks up a connection no one authorized, and the control that could narrow it answers to a different function on a different clock.
As a GSC mechanism, security is that same access and exposure control, wired to the conn. The seat that is accountable for the model is the seat that can narrow what it reaches and revoke what it should not, in the window where the reach is still small. Not a new security team. The controls you already have, connected to the accountable seat.
The brake, not the bureaucracy
Bureaucracy asks and waits. It routes the concern to a committee, opens a ticket, schedules the review. By the time it answers, the machine-speed system has run the drift across every case in the queue. A brake does not ask. It acts where the work happens, because the seat that owns it set it to.
Picture an agent that handles customer refunds. One afternoon it attempts to approve a refund above the amount it was cleared to approve, and it tries to retrieve account records outside the cases it was assigned. One event, two mechanisms, two different jobs. The guardrail caps the action: the refund above the limit is held at the boundary before it goes through, whatever the agent decided. Security caps the reach: the attempt to pull the extra records meets an access control that blocks it and revokes the access if it was ever granted too broadly. One constrains what the model does. The other constrains what it can touch. Neither waits for a meeting, and both answer to the same seat.
So ask it plainly. You may have guardrails, and you may have capable access controls run by capable teams. The question is not whether one person holds every power. It is whether the seat accountable for the model can secure action in time: set the boundaries, tighten them, and require the reach to be narrowed or cut the moment it drifts, without waiting on a function that answers elsewhere. Distributed controls are not a brake until an accountable seat can call the stop and have it happen.
Security is the middle block the conn holds. Guardrails and security, the two ways an accountable seat constrains a running model instead of only documenting it. Governance keeps the model honest. Security stops it when honesty is not enough. Control completes the structure, and closes the loop.
