Governance overview

Where you areCopy Anchor Link

People across your organization already use AI tools and agents. Nobody can say what data they share, which models they call, or what they do on the organization's behalf. Procurement, legal, and security are asked to write rules for tools they cannot see.

Oxagen is the agent control plane for that work. Every governed action passes through the same invoke() boundary, whether a person takes it in the app, an agent takes it on a schedule, or an MCP client in a developer's IDE calls it. When a task needs a capability, the agent asks. A rule answers: allowed, denied, or routed to a person. A denied action does not run, and the record keeps every answer.

Three scopesCopy Anchor Link

Governance in Oxagen has three scopes:

Organization → governance rails, billing, global policies
   └── Workspace → operational units where agents work
          └── Principal → human, agent, or service account

The organization is the customer entity. It owns billing and the member roster, and it sets the outer bounds for every workspace. The IAM resolver has an org-enforced policy tier that workspaces cannot override, but that tier is not live today. See RBAC and roles.

Workspaces are operational units, one per team, project, or environment. Each workspace has its own member roster, model defaults, and plugin installs. A workspace can narrow what the organization allows and never widen it.

Principals are people, agents, and Oxagen API keys. The same role and grant model governs all three, so an agent's grants are as visible and auditable as a person's.

What every action passes throughCopy Anchor Link

Every capability call, from the app, the REST API, the MCP server, or an agent run, enters the same invoke() kernel. The checks run in this order, and the first one that refuses ends the call before the handler runs:

Three properties of this path matter for a governance review:

• An IAM check that cannot be evaluated denies. A database outage or resolver bug during the check fails closed with authz_denied. It never lets the call through.
• A call that needs approval is refused now and recorded. A pending_approval outcome refuses the call and records an access request (arq_…). There is no in-app screen for answering these requests yet.
• Every refusal is recorded. Each denied branch writes a security event with its error code, so the audit log shows refused calls, not only allowed ones.

Key governance controlsCopy Anchor Link

Role-based access controlCopy Anchor Link

Eight built-in human roles cover most enterprise access patterns. Four are org-scoped (Owner, Admin, Compliance, and Billing), and four are workspace-scoped (Owner, Admin, Member, and Viewer). A workspace's Owner and Admin can do everything in that workspace. Agents get three roles of their own (Agent Observer, Agent Contributor, and Agent Operator). See Agent roles. Organization → Roles lists roles and permissions. Owners and Admins can create, edit, and delete custom roles. Built-in roles stay read-only. See RBAC and roles.

PluginsCopy Anchor Link

Every plugin install is workspace-scoped. A plugin installed in one workspace is not visible to any other workspace. The credential a plugin needs stays in Oxagen, held by the workspace, and no agent sees it. There is no org-level plugin denylist today. See Plugin governance.

Model governanceCopy Anchor Link

Your subscription plan decides which models are on offer. A workspace Owner or Admin sets the workspace's default text tier and model. There is no per-workspace model allowlist yet, so a default chooses a model but does not forbid others. See Model governance.

Access reviewsCopy Anchor Link

Review membership on the organization page and permissions under Organization → Roles. Query membership and role events with query_audit_log. The former Access Reviews screen is not part of the current app.

What you cannot do from the appCopy Anchor Link

Some governance controls need your infrastructure administrator:

• Changing the TENANT_RLS_ENFORCEMENT_ENABLED environment variable, which controls database-layer RLS enforcement (true in production).
• Provisioning the non-superuser database role.

SIEM export is not available. Pull audit events into an external SIEM on a schedule with query_audit_log. See Audit logging.

Contact success@oxagen.sh for infrastructure-level governance changes.