Skip to content

Governance and Safety

Every action that a GloriaMundo workflow takes passes through a governance system before it executes. This is not a single check but a layered set of guardrails, each serving a different purpose. The result is that your automations have safety built in from the start.

This page covers the governance system in depth.

The Layered Safety Model

When a workflow step is about to execute, the governance system evaluates it through several layers, in order:

  1. Kill switch check: Is there an active emergency stop for this workflow, agent, user, or the entire platform?
  2. Blocked actions check: Has the user explicitly blocked this type of action in their settings?
  3. Constitution check: Does this action violate any fundamental guardrail rules?
  4. Policy evaluation: Does a policy rule apply to this action (deny, require approval, or modify)?
  5. Approval check: Does this action require user approval based on settings, cost thresholds, or strictness mode?

If the action passes all layers, it proceeds. If any layer blocks it, the workflow receives a clear reason why.

Default Policies

GloriaMundo ships with a set of system policies that apply to all users. These provide a sensible baseline of protection:

  • Block bulk deletes: Actions that would delete data in bulk (DELETE_ALL, BULK_DELETE, DROP, TRUNCATE) are blocked outright.
  • Require approval for financial actions: Any action involving payment services (Stripe, PayPal, bank transfers) requires your explicit approval before executing.
  • Require approval for public posts: Social media publishing actions (Twitter, LinkedIn, Facebook, Instagram) require approval. You review the content before it goes live.
  • Require approval for outbound email: Sending emails to external addresses requires approval, so nothing leaves your account without your knowledge.
  • Block credential exposure: Actions whose parameters contain passwords, API keys, tokens, or other credentials are blocked to prevent accidental data leakage.

These policies cannot be deleted, though you can layer additional policies on top of them.

The Approval System

Many governance decisions result in "require approval" rather than an outright block. When this happens, the action is queued for your review. You see what the workflow wants to do, why approval was triggered, and you can approve or reject it.

Common triggers for approval:

  • Write actions (create, update, delete, send, publish) when you have enabled the "require approval for writes" setting
  • Actions whose estimated cost exceeds your auto-approve threshold
  • Irreversible actions when you are in strict audit mode
  • Any action matching a "require approval" policy

For more on managing approvals, see Approvals Overview.

Constitution Rules

The constitution is a set of fundamental guardrail rules that agents must follow. These are the highest-priority governance mechanism. Constitution rules can be:

  • Global: Platform-wide rules set by the system (apply to everyone)
  • User-specific: Rules you define for your own agents
  • Agent-specific: Rules scoped to a particular agent

Constitution rules are immutable by design. Once created, they cannot be edited. They can only be deactivated if they are no longer needed. This prevents accidental weakening of safety constraints.

Each rule has an enforcement level:

  • Strict: Violations are blocked outright
  • Warn: A warning is logged, but the action proceeds
  • Log: The event is recorded for later review

Kill Switch

The kill switch is an emergency stop mechanism. It can be activated at four scopes:

  • Global: Halts all agents across the entire platform
  • User: Halts all agents belonging to a specific user
  • Agent: Halts a specific agent
  • Workflow: Halts a specific workflow

When a kill switch is active, every action for the affected scope is immediately blocked. In-flight operations for user-level and global scopes are cancelled, including any pending approvals.

The kill switch is designed for situations where something needs to stop right now. It takes effect instantly.

User-Configurable Safety Settings

You control several governance behaviours through your Settings:

  • Audit enabled: Turn governance checks on or off. When disabled, all actions are allowed without evaluation. (Enabled by default.)
  • Audit strictness: Choose between balanced and strict modes. Strict mode requires approval for all irreversible actions.
  • Require approval for writes: When enabled, all write actions (create, update, delete, send) require your approval before executing.
  • Auto-approve threshold: Set a cost threshold. Actions below this amount are approved automatically; actions above it require manual approval.
  • Blocked actions: Maintain a list of specific actions that should never execute. Workflows that attempt a blocked action receive an error with guidance to adjust the workflow.

How This Fits Together

The governance system works alongside the rest of the platform's safety mechanisms:

  • Virtual Run lets you preview what a workflow will do before execution. Governance checks apply during live runs, not during Virtual Run previews.
  • Enhancement reviews workflows for reliability and security improvements, catching potential issues before they reach the governance layer.
  • Credit limits and budgets provide financial guardrails that complement the action-level governance described here.

The goal is defence in depth. No single mechanism is responsible for keeping things safe. The layers work together so that your automations have guardrails at every stage, from generation through to execution.