Inspiration
A friend proudly told me he had built a skill library for his company: “Run one command, and every project gets the skills.”
I asked him: “What stops the agents from doing something they shouldn’t?”
He had no answer.
That is the problem Gjallar is trying to solve. Most agent-skill libraries focus on giving agents more abilities, but say little about permissions, approvals, or audit history.
For companies, the biggest question is often not “Can the agent write code?” It is:
What is the agent not allowed to change, and who approved those rules?
What it does
Gjallar is a policy and approval system for coding agents such as Codex, Cursor, and Claude Code.
It checks a proposed write before the file is changed. The exact mechanism depends on the runtime:
Claude Code uses a native PreToolUse hook to block unsafe writes. Codex currently cannot run the plugin’s bundled hook, so Gjallar provides an MCP write gateway called policy_apply_patch. Codex repositories stay read-only to native tools, so approved writes must go through the gateway.
This means the policy is enforced outside the model. The agent cannot simply ignore it or reason its way around it.
For example, Gjallar can stop an agent from:
Creating or modifying .env files Hardcoding API keys Editing lockfiles by hand Crossing protected architecture boundaries Writing credentials into scripts
A rule can block a write, warn the agent, record it for observation, or require human review.
Rules also have a lifecycle:
Observed → Candidate → Under review → Approved → Active
Deny rules can never become active automatically. A named human must approve them. When a rule changes, Gjallar creates a new version linked to the old one, so the history remains visible.
Every intercepted write is logged. Repeated violations can be grouped into new rule candidates, but a human still decides whether those candidates become active rules.
Gjallar also separates guidance from enforcement:
Important security and privacy rules are always included as resident guidance. Other relevant rules are retrieved based on the task and target path. The enforcement engine still checks every write against the complete active rule set.
Retrieval helps the agent understand the rules, but it does not decide whether a write is allowed.
This protection has a cost. Our benchmarks found that the Codex gateway can increase token usage by roughly 35% to 137%, depending on the task. Small tasks show the largest percentage increase because the gateway and tool schemas have a mostly fixed overhead. We publish those results instead of pretending the protection is free.
How we built it
Gjallar’s original rule and telemetry model came from a larger local-LLM research project. The Codex integration was built during this submission period, using Codex itself.
The Codex adapter is an MCP server, not a hook.
Its main tool is policy_apply_patch. It:
Checks the host setup and workspace registration. Evaluates the proposed patch. Allows, denies, or sends the patch for human review. Writes only inside a registered workspace.
These checks happen inside one call, so the agent does not need to run separate setup checks before every write.
The plugin includes two skills:
gjallar-policy for normal coding tasks gjallar-policy-rules for adding or changing policies
Keeping rule management separate prevents ordinary coding tasks from loading instructions they do not need.
Rule changes follow a controlled flow:
Propose rule → Pending request → Human approves or rejects → Apply
The plugin also includes a CLI command for unregistering a workspace without changing its rules.
Every demo starts with an isolated CODEX_HOME and a temporary repository. The setup and benchmark numbers therefore represent a clean installation, not a preconfigured environment.
During development and testing, Gjallar stopped ten unsafe write attempts before they reached disk. These included hardcoded keys, credential files, manual lockfile edits, and architecture violations.
One test found a real gap: an AWS key inside a shell script was not covered by the original rule. We fixed it through the same propose, approve, and apply workflow instead of silently editing the rule.
The new Codex work is visible in the project’s commit history.
Challenges we ran into
The first challenge was understanding the difference between advice and enforcement.
Our early version placed rules in the prompt and expected the model to follow them. That was not reliable. Models can forget instructions or convince themselves that an exception is reasonable.
We therefore separated the system into two parts:
Guidance helps the model make better decisions. Enforcement independently decides whether a write is allowed.
The model is never the security boundary.
We also considered automatically promoting repeated violations into active deny rules. That would have looked impressive in a demo, but it would also have been dangerous. Instead, every generated or telemetry-based rule must pass a human approval step enforced by the state machine.
The final challenge was context size. Sending every rule on every turn does not scale. Gjallar sends only resident and relevant guidance to the model, while the policy engine checks the complete rule set outside the model.
What we learned
Capability tooling — skills, MCP — is way out ahead of governance tooling right now. Whoever adopts agents fastest is also going to be the first team that gets asked "who approved this?" and has no answer. And building the governance layer using the very agents it's supposed to govern turned out to be more than just possible — it was honestly the fastest way to generate test cases we could actually trust, because the tool kept catching real mistakes as we made them.
What's next for Gjallar
Next, we plan to add:
Support for more coding-agent runtimes A simpler approval interface for non-developers Better workflows for senior engineers reviewing policy changes Domain-specific rule packs based on real incident histories
The long-term goal is simple: coding agents should become more capable without becoming less accountable.
Log in or sign up for Devpost to join the conversation.