Where AI agent policy is actually enforced. Server-side, on the device — and why it decides whether rules hold.
Every AI coding agent now ships admin controls. The question that separates them is where those controls are enforced. A rule in a settings file on a developer's laptop can be edited or bypassed on that laptop. A rule checked on a server before the action runs can't.
Updated 16 October 2026
A setting on the laptop is a preference. A check on the server is a control.
Client-side enforcement means the agent reads its rules from configuration on the developer's machine and applies them to itself. It's useful — it stops honest mistakes — but whoever controls the machine controls the rules. Several vendors describe their own client-side allowlists as a convenience rather than a security boundary.
Server-side enforcement means the action has to pass through a server that holds the credentials and decides, before anything runs, whether this person may do this. Edit the laptop all you like: without the server's yes, the database or tool never sees the call.
Not everything can be enforced on a server. A shell command runs on the developer's own machine, so it can only be governed there. The practical design is both: put every shared system — databases, internal tools, MCP servers, models — behind a server that decides, and lock the device policy for what happens locally. That's how Kryex is built.
Six requirements for enforcement that holds.
Keep credentials off the laptop
If the developer's machine holds the database password or API token, the agent can always reach the system directly — whatever the policy says.
Credentials for governed systems stay encrypted on Kryex Server. The desktop only sends which tool and which arguments, so every call has to go through the server.
Decide on the server, before the action runs
Logging an action after it ran is evidence, not control.
Each database statement, MCP tool call, browser and web action is checked against the person's live grant on Kryex Server first. Default is deny, and calls fail closed if the server can't be reached.
Grant per person, per system, per level
One switch per tool is too coarse — the same tool can read a record or delete a project.
People get READ, WRITE or ADMIN independently on each database and each MCP tool. The agent asks for more in the conversation, and an admin decides.
Lock what can only run on the device
Shell commands and file edits happen on the developer's machine, so their policy has to be enforced there and kept from drifting.
Admins set Allow, Ask or Block per command category — or block shell commands entirely. Ask and Block apply in every mode, Bypass included, and IT can lock the policy on each device, even offline.
Re-check when anything changes
A decision made yesterday shouldn't hold after access is revoked or a tool changes.
A suspension takes effect on the next model call. A tool whose definition changes goes back to quarantine, and tier changes are re-checked on the agent's next turn.
Record the decision where it's made
The audit trail should come from the component that decided, not from the client that asked.
Kryex Server writes every governed decision to a hash-chained, append-only audit log, with arguments stored only as a hash.
Common questions.
What is the difference between client-side and server-side policy enforcement for AI agents?
Client-side enforcement applies rules from configuration on the developer's machine, so whoever controls that machine can change them. Server-side enforcement routes each action through a server that holds the credentials and decides before the action runs, so editing the laptop can't bypass it.
Is a managed settings file enough to govern an AI coding agent?
It helps — it stops accidental misuse and sets sensible defaults — but it lives on the device it governs. For databases, internal tools and MCP servers, keep credentials on a server and authorize each call there; use managed device settings for what can only run locally.
Can shell commands be enforced on a server?
Not directly — a shell command runs on the developer's own machine. They're governed by a device policy, such as Kryex's Allow, Ask or Block per command category, locked on each device. What a server protects is the shared systems those commands might try to reach, by keeping their credentials off the machine.
What happens in Kryex if the policy server is unreachable?
Governed calls fail closed: with no answer from Kryex Server, the database, MCP tool or browser action doesn't run.