Your organisation sets how much it asks
Your organisation decides how much the agent asks first, and every rule can only get stricter as it moves closer to the person.
- Read and searchon its own
- Edit files in the projecton its own
- Run declared checkson its own
- Other commandsasks first
- Write outside the projectasks first
- Push and open PRsoff until enabled
The platform default. Edits in the project run; commands and writes outside it stop at a card.
- platformguarded
- organisationinherit
- memberinherit
- workspaceinherit
Security profile resolves to guarded
An organisation can tighten a platform setting, never loosen it.
Settings you can see and defend
"Governed" means you chose the setting. Kodela makes the setting visible, per person, and records every time it mattered.
"Allow everything" is unsafe and "allow nothing" is useless. Most tools offer only a global on/off. Kodela turns "should the agent be allowed to do that?" into:
- a profile per member (supervised, assisted, autonomous);
- approval cards for anything that leaves the workspace;
- a validation gate that refuses a push without a passing check;
- a set of switches that ship off until you turn them on.
Prove a push was tested
The validation gate runs in the git broker. A push needs a passing verdict, produced on the host, for its exact commit and repository.
- Commita41c09e
- Check on hostnpm test
- Verdictbound to commit and repo
- Pushfeature/dev01/signup
- Broker verifiesverdict for this exact commit?
With no passing verdict for the exact commit, the broker refuses the push and names the missing check.
- A check the upstream default branch declares cannot be removed to get past the gate.
- The gate does not replace CI. It refuses a push that has no passing verdict for that commit. Your CI still runs.
- Off by default. An admin approves the project's check, then turns the gate on.
- Not yet recorded on a live GitHub push.
The approval card
Cards say exactly what will happen, and a refusal says why in a sentence.
- The turn runsReads and edits inside the project, as the profile allows.
- It parks
awaiting_approvalA command or a write outside the project ends the turn with a card. - Someone approvesSelf-approval is the default and advisory. Binding and second-person approval are organisation settings.
- The turn resumesEvery approval lands in the audit chain, so you can show an auditor who approved what.
"Why it's stuck" replaces guessing
A governed background run must pass five gates. The diagnostic names the one holding it, in a sentence.
- Governed background runs need a per-organisation grant.
- Limit: the grant lapses on each new release until the evidence is re-run.
Switches that ship off
Each one is off until an admin turns it on. Every change to a setting is audited.
- Memory
- MCP servers
- Subagents
- Skills from the repo
- Agent git push
- Desktop IDE attach
- File transfer
- Workspace-to-portal channel
- AI inside apps
- Validation gate
Defaults and limits
| Capability | Default | Limit |
|---|---|---|
| Agent profiles per member, with an operator floor | assisted | autonomous means no card |
| Approval cards; self or second-person | self, advisory | binding is an organisation setting |
| Validation gate on push | off | not yet seen on a live GitHub push |
| Declared checks run without a card | empty | the allowlist is the governance |
| Strictest-wins settings across four scopes | on | n/a |
| Security profiles (open, metered, guarded, strict) | guarded | open and metered mount the git token in the container |
| Switches that ship off | off | each needs an admin to turn it on |
| Governed background runs (live execution grant) | per-organisation grant | the grant lapses on each new release until evidence is re-run |
| "Why it's stuck" diagnostics | on | n/a |
Operators see posture across organisations on the Governance page, and tenant-audit lists organisations looser than the floor. bin/policy is the operator CLI; there is no public API.
Two changes an admin makes
Tightening for a contractor
- Set the contractor's profile to supervised.
- Every write and command then asks first. The organisation default stays assisted.
Turning on the gate
- An admin approves the project's test check.
- They turn on the validation gate.
- The next push without a passing verdict is refused with a sentence naming the missing check.
Questions
Can a member loosen their organisation's rule?
No. Settings only tighten toward the person.
What does autonomous mean?
The agent does not stop for cards within what the profile and your settings allow. It is still inside the workspace, the egress rules and the audit.
Does the gate replace CI?
No. It refuses a push that has no passing verdict for that commit. Your CI still runs.
Does a profile limit what the agent can reach?
No. Profiles decide how much the agent asks, not what it is able to reach. Reach is the egress and broker layer's job.
What it does not do yet
- A live GitHub push through the gate has not been recorded.
- Grants for governed runs must be re-issued after each release.
- Policy as code in your repo.
Say yes to agents without saying yes to everything
Read what each layer refuses, then bring your own rules to a pilot.