AI agent security: agents 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's approach to AI agent governance inverts that: the model has judgment about the work, and none about its own authority.
Access is granted, never inherited.
Least privilege in Orgabot means an agent working on your behalf is not you. An Orgabot agent 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 that stage cannot reach production, regardless of what the model decides. A connector's effective permission is the narrowest of three independent limits: what the upstream application allows, the ceiling configured for the connector in Orgabot, 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. Authority does not accumulate as a mission moves between stages, and revoking a grant takes effect on the next action rather than the next redeploy, so tightening access never waits on a restart.
- 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
Your secrets are not prompts.
Orgabot keeps credentials out of model context, because a credential in a prompt is a credential you have published: to a transcript, to a log, to a provider's request history, and to whatever the model decides to echo back. Orgabot treats credentials as an infrastructure concern, the same way any other production system does. An agent asks for an action, a brokered tool performs that action with the credential the operator configured, and the result comes back to the agent. The agent never needs to know the secret to use it, so there is no moment where handing the secret over is the convenient thing to do. Secrets are redacted from transcripts, logs, and diagnostics, and a credential handle is what travels between components, never the credential itself. This is also what makes model providers substitutable: if a secret never reaches a vendor, changing vendors is not a credential rotation exercise.
- 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
Isolated by construction.
Execution isolation in Orgabot is not a matter of asking an agent to be careful. Each Orgabot mission works in its own git worktree on its own branch, so a failed or malicious run has touched nothing you were using, and work reaches the world only through brokered tools that check policy before acting. The command broker refuses destructive shell patterns, and 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. Orgabot is local-first: it runs on your laptop against your repositories with your credentials and needs no hosted service, which for a team that cannot send source anywhere is the whole deployment story. The same control plane runs on your own servers or in public cloud when you want shared visibility and scheduled work. Where Orgabot runs changes the operations story, not the security model.
- 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
Some decisions are structurally not the agent's to make.
Separation of duties in Orgabot is enforced in code rather than described in a policy document. The agent that produced a change is ineligible to review it, approvals are routed to the role that owns the decision, and an approval authorizes one named operation rather than a general permission to proceed. A producer cannot waive its own verification gate, and policy that would weaken a required gate is refused unless a matching approval exists. Every Orgabot gate fails closed. 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. Each of those is the same rule stated once: in Orgabot, the absence of an observation is never a passing observation.
- 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
Approval gates: what each one checks, and who can pass it.
Orgabot's approval gates treat verification, review, approval, and policy as one mechanism. Every gate names the evidence it stands on, records who decided it, and has exactly two outcomes: approved, or rejected back to the builder with the feedback attached. The verification gate needs an observed exit code of zero from the project's own test command, run by Orgabot on the exact commit. The independent review gate needs a review record at the current head from a reviewer that is not the producer. The CI gate needs green required checks on that exact SHA. The approval, access change, and release promotion gates each need a resolved approval bound to the specific operation, from the role that owns the decision. The policy gate checks, before a run exists, that the workflow includes every gate policy requires. The table below lists each Orgabot gate, what it checks, the evidence it needs, and who can pass it.
| Gate | What it checks | Evidence it needs | Who can pass it |
|---|---|---|---|
| Verification | The project's own verify or test command, run by Orgabot on the exact commit, not by the worker that wrote it | An observed exit code of zero. A summary or a confidence is refused; no configured command is recorded as a skip, never a pass | Orgabot, automatically. The producer cannot waive it |
| Independent review | The diff against the project's review policy and configured scanners, with full coverage of every changed file | A review record at the current head with no open blocking findings. A coverage gap is not a mergeable approval | A reviewer that is not the producer, even when one actor holds both roles |
| CI authority | Required GitHub Checks for the pull request head | Green checks on that exact SHA. A green result on a different commit never counts | Your CI, observed by Orgabot |
| Approval | Opening a PR, merging, deploying, spending, or granting access | A resolved approval for the named operation, or a policy that permits it | The role that owns the decision. The requester cannot approve its own request, except under an audited solo-approval mode |
| Access change | What a role may reach: tool, connector, and capability grants | An approval; a sensitive grant also gets independent least-privilege review | The owning role, or a CISO agent only inside a bounded envelope that escalates everything by default |
| Release promotion | Tag and release operations for the next environment on the chain | An approval bound to those exact operations, SHA, and release title, then a re-read showing the tag at that SHA | The role that signs off on the target environment. Unregistered environments are treated as strictest |
| Policy | That the workflow includes every gate policy requires, checked before a run exists | A readable policy. An unreadable one blocks, and a locked gate cannot be disabled | Evaluated at resolution. Loosening a policy needs an approval from the supervising role |
Evidence, not assurances.
Orgabot's audit trail is a byproduct of running the work, not a report assembled afterwards. The record that let a change advance is the same record an auditor reads later, which is why the two cannot quietly disagree about what happened. Every elevated action is recorded with the authority it acted under, and every gate decision carries the decider, the evidence, and whether the decision was admitted. Refused decisions are recorded as refused rather than dropped, so the trail shows what Orgabot declined to do as well as what it did. The organization ledger is hash-chained, which makes tampering detectable rather than merely unlikely. Because the event history is complete, an Orgabot run can be replayed from that history instead of reconstructed from memory and logs. When a security lead asks why a change shipped, the answer is the evidence that shipped it, not an assurance that the process was followed.
- 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 Orgabot provides is the machinery an audit asks about: access scoped to a role and a stage, approval records that carry identities, separation of duties between the agent that produced a change and the one that reviewed it, policy enforcement that fails closed, and an evidence trail you can produce on request. Those are the controls an auditor checks for when AI agents are writing and shipping code, and Orgabot records them as a side effect of running the work rather than as a separate compliance exercise. Earning the certification is still work, and it is still yours: an auditor still needs your policies, your scope, and your people. Orgabot's contribution is that the technical evidence for agent activity already exists in a form you can hand over, instead of being reconstructed from chat logs after the fact.
Found something? Tell us privately.
Orgabot publishes a private vulnerability disclosure channel, because a security lead evaluating a tool looks for a way to report a problem before they look for anything else. Send vulnerability reports to security@orga.bot and find the machine-readable version of that contact at /.well-known/security.txt in the RFC 9116 format, so a researcher's tooling lands on the same address a person would. Please report privately and give us a chance to fix the issue before public disclosure. Orgabot is a private alpha built by one developer, so there is no bounty program, but there is a real person reading that address, and every report gets a reply. A report that names the affected component, the steps to reproduce, and what you observed gets fixed fastest. The security model described on this page is fair game in the same channel: if a claim here turns out to be wrong, that is a bug too.
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.