Agents should never get more access than the task requires.
Most agent tooling asks you to hand over a broad credential and trust the model's judgment about when to use it. Orgabot inverts that: the model has judgment about the work, and none about its own authority.
Access is granted, never inherited.
An agent working on your behalf is not you. It holds the grants its role was given, clamped by the stage it is currently in, and nothing more. If a stage does not need production access, the agent running it cannot reach production, regardless of what it decides.
- A role starts with no access and receives grants explicitly
- A grant names one tool, not a category of them
- A stage clamps what its role may reach while it runs
- Authority does not accumulate as a mission moves between stages
- Revoking a grant takes effect on the next action, not the next redeploy
A connector's effective permission is the narrowest of three independent limits: what the upstream application allows, the ceiling configured for the connector, and the grant held by the specific role. Nothing caches the result of that calculation, because a cached permission is a fourth authority that goes stale exactly when it matters.
Your secrets are not prompts.
A credential in model context is a credential you have published. It lands in a transcript, in a log, in a provider's request history, and in whatever the model decides to echo back. So Orgabot never puts one there.
- Credentials are held by the tool that uses them, not by the agent that calls it
- The broker performs the call; the agent receives the result
- Secrets are redacted from transcripts, logs, and diagnostics
- A credential handle travels between components; the credential does not
- Nothing that can write configuration can widen its own access
The design philosophy
Credentials are an infrastructure concern, the same way they are in any other production system. An agent asks for an action, a brokered tool performs it with the credential the operator configured, and the result comes back. The agent never needs to know the secret to use it, which means there is no moment where handing it over is the convenient thing to do.
This is also what makes model providers substitutable. If a secret never reaches a vendor, changing vendors is not a credential rotation exercise.
Isolated by construction.
Containment is not a matter of asking an agent to be careful. Work runs somewhere it can fail without consequence, and reaches the world only through tools that check policy first.
- Each mission works in its own git worktree on its own branch
- A failed or malicious run has touched nothing you were using
- Destructive shell patterns are refused by the command broker
- A worker that must self-verify says so explicitly and is granted shell for that reason
- Text an agent reads from the outside is labelled untrusted data, never instruction
Nothing has to leave the machine
Orgabot is local-first. It runs on your laptop against your repositories with your credentials, and needs no hosted service to do its job. For a team that cannot send source anywhere, this is the whole deployment story.
Or run it where your infrastructure is
The same control plane runs on your own servers or in public cloud when you want shared visibility and scheduled work. Where it runs changes the operations story, not the security model.
Some decisions are structurally not the agent's to make.
Separation of duties is enforced in code rather than described in a policy document. The producer of a change is ineligible to review it, and an approval authorizes one named operation rather than a general permission to proceed.
- The agent that produced a change can never review it
- Approvals are routed to the role that owns the decision
- An approval authorizes one specific operation, not a class of them
- Policy that would weaken a required gate is refused unless a matching approval exists
- A producer cannot waive its own verification gate
An unreadable policy blocks; it does not read as "no policy". A gate that cannot be evaluated holds the work; it does not pass it. A required gate cannot be disabled by configuration at any level, and the attempt is refused rather than silently ignored. Every one of those is the same rule: the absence of an observation is not a passing observation.
Evidence, not assurances.
The audit trail is a byproduct of running the work. The record that let a change advance is the same record an auditor reads afterwards, which is why it cannot quietly disagree with what happened.
- Every elevated action is recorded with the authority it acted under
- Gate decisions carry the decider, the evidence, and whether they were admitted
- Refused decisions are recorded as refused, not dropped
- The organization ledger is hash-chained, so tampering is detectable rather than merely unlikely
- Runs can be replayed from the event history instead of reconstructed
Supports the controls, does not sell you the certificate.
Orgabot is not SOC 2 certified and does not make you compliant. What it provides is the machinery an audit asks about: scoped access, approval records with identities, separation of duties, policy enforcement, and an evidence trail you can produce on request. Earning the certification is still work, and it is still yours.
Build the organization your agents can safely operate inside.
If you are evaluating this for a team with real compliance obligations, the details above are the ones worth arguing with. Come do that in the Discord.