Enterprise

Governance your auditors can read line by line.

Roles decide who approves. Budgets are set in dollars. Every approval, override and change is on the record.

Roles

Who may approve is a role, not a habit.

Organisation and project roles govern who may approve. The rules travel with the change, not with whoever happens to be online.

  • Organisation and project roles

    Who may approve a plan, clear a sign-off or raise a budget is set per organisation and per project, and audited when it changes.

  • Nobody approves their own change

    The author is never their own approver. On a high-risk change, a second approver who is neither the first nor the author.

  • Higher risk, more names

    The change’s own signals set its risk, and the risk sets who must sign off — a named approver from the owning team on a critical change.

  • One approval wins

    Compare-and-set: a sign-off is cleared once, by one person, and the record says who.

  1. Per changea budget on every runset on the automation
  2. Per memberthe same ceiling for everyonenobody’s share shrinks when someone joins
  3. Per organisationone cap the whole organisation spends againsta run at its limit stops and asks

Budgets

Dollars at every level.

Budgets are stored and enforced in dollars, because that is what the people setting them think in. Tokens are derived for display. Every stage reports what it spent, rolled up per change.

Audit trail

Who did what, on the record.

An audit trail records who approved, started, overrode and changed what. And every pull request carries its own: the plan, the checks, the approvals, the spend.

  1. approvedA sign-offBy name, with the time.
  2. startedA changeAnd what started it: the label, the mention, the schedule.
  3. overrodeA budgetWith the justification attached.
  4. changedAn automationVersioned; a run in flight keeps the definition it started with.

Every change runs in its own sandbox with no route to the internet; the rules that govern it live outside the repository; what it reads from tickets and diffs arrives fenced; what it writes carries its own identity; and it never merges its own pull request. Unattended is earned per automation, never switched on. And the edits you approve to an agent role survive an upgrade.

Each control is a written decision — ADR 0003, ADR 0006, ADR 0007, ADR 0008 and ADR 0009 — and we share the decision records with your security team on request.

In the product:sandbox → Confinementfenced content → Untrusted Contentwrite-back → Platform Action

Enterprise controls

Deployment and identity, on the roadmap.

Today DevByte runs as a managed control plane with sandboxes it provisions. A dedicated or on-premise deployment, single sign-on over SAML, SCIM provisioning and a written retention position are on the roadmap — and we say so rather than imply them.

  • On-premise or dedicated deploymentOn the roadmap · ask us for timing. Not available today.
  • Single sign-on over SAMLOn the roadmap · ask us for timing. Not available today.
  • SCIM provisioningOn the roadmap · ask us for timing. Not available today.
  • A written data-retention positionOn the roadmap · ask us for timing. Documented per deployment; ask us for yours.

Bring your governance questions.

Roles, budgets, the audit trail and the sandbox — with the decision records behind each.