Guardrails and Approvals
Nova can change production, so every action it takes passes through your organization's guardrails first. For each action, the guardrails decide one of three things: Nova does it, Nova asks first, or Nova does not do it. Every decision is recorded.
How it works
Before Nova runs anything, it sorts the action into a category and applies your organization's rule for that category:
- Allowed: the action runs.
- Requires Approval: Nova pauses, shows you exactly what it wants to do, and runs it only after someone approves.
- Blocked: the action never runs. Nova is not offered blocked actions at all, so it cannot try them another way.
The same guardrails apply in Nova Cloud, in your terminal with astroctl nova, and in Slack.
Categories and safe defaults
Every organization starts with safe defaults. Reading is free, changing waits for you, and destroying or touching secrets is off.
| Category | Covers | Default |
|---|---|---|
| Observability & Monitoring | Cluster health, metrics, events, resource status | Allowed |
| Messaging & Notifications | Sending messages, creating channels, notifications | Allowed |
| Sensitive Data Access | Application logs, debug output, security scan results | Requires Approval |
| Changes & Remediation | Deploys, restarts, rollbacks, updates to running resources | Requires Approval |
| Scaling & Resizing | Capacity, replica counts, resource allocations | Requires Approval |
| Infrastructure Provisioning | Creating and modifying infrastructure | Requires Approval |
| Destructive Actions | Deleting or permanently destroying resources | Blocked |
| Secrets & Credentials | Reading or changing tokens, keys, certificates, passwords | Blocked |
| Infrastructure Teardown | Destroying and decommissioning infrastructure | Blocked |
Tools from the skills you add, including your own MCP servers, go through the same guardrails.
How Nova tells a read from a change
- Built-in skills say what each of their actions does, and Nova uses that.
- Any other tool is judged by the hints its server publishes about it:
- A tool the server marks read-only runs as a read.
- A tool the server marks destructive follows your Destructive Actions rule.
- Any other tool is a change and follows your Changes & Remediation rule. That includes a tool whose server says nothing, so by default Nova asks before it runs.
- Your own MCP servers start untrusted. Every call to one of their tools asks a person, whatever the hints say. An organization owner or admin can turn on Trust this server in the server's settings under Skills, and Nova then goes by its hints as above. Trust never skips what your rules require, and any change to the server's tools, or to its address, removes it.
- Nova never decides from a tool's name.
Each entry's trace in Activity records which of these decided: the skill's own declaration, the server's hint, or the default for a tool that says nothing.
Approve or deny an action
When an action needs approval, Nova stops and shows you the action and what it will touch.
Nova Cloud
Approve or deny from the card in the conversation. Nova continues as soon as you decide.
Terminal
astroctl nova shows the request in the conversation; answer it there with /approve. An investigation's questions are answered from /investigations inside astroctl nova.
Slack
Nova posts the request in the thread with a link, and you approve or decline it in the console. In an alert's thread, a low-risk fix can be approved from the thread when your organization allows it (see Fixes and mitigations).
API
Pending approvals can be listed and answered through Nova's API: see the API reference.
Approvals do not wait forever. If nobody decides by the deadline (15 minutes by default, set in Settings → Guardrails, in Advanced under Who approves), the action is declined and nothing runs.
A fix an investigation proposes
When an investigation finds a cause and proposes a change, the card shows Let Nova fix it with the action, its risk and its target. Approve it from the card, or take it over with I'll fix it myself. Fixes and mitigations walks through approving a change, and the card reference covers the whole card.
- The approval window is 15 minutes by default; owners and admins can set it from 1 to 60 minutes. The card shows the deadline. If nobody decides in time, the investigation closes as Approval expired and Nova makes no change. An approval that arrives late is refused.
- Exactly one decision counts. If two people decide at once, or a decision races the deadline, one wins and the others are told the investigation has already moved on.
- Stop ends an investigation while it is running or applying a fix, and Nova makes no further change. I'll fix it myself hands the fix to you, and Nova makes no change in that investigation.
- Approval history appears on the card: whether Nova has proposed this change for this target before, how often it was approved, and how often the app was healthy afterwards.
- The card, and the alert's Slack thread if an alert started it, say how it ended: Fix applied, Fix failed, Fix held, no change (for example, only a preview ran), Fix rejected, Approval expired or Cancelled.
From a terminal, /investigations in astroctl nova answers the card; Nova's API does the same.
Sensitive Data Access is granted per app and per investigation. When an investigation needs a sensitive read, such as an app's logs, it asks. Once you allow it, Nova can make those reads for that app in that investigation, for your organization's access window (60 minutes by default). Until you do, it skips them, carries on with what it can see, and records each skipped read as Withheld.
Change your guardrails
Open Nova, open Settings (the gear at the bottom of the sidebar) and choose Guardrails. The page lists every category under its current rule, in three columns: On its own (Allowed), Asks first (Requires Approval) and Never (Blocked). Open a category to change its rule.
- Organization owners and admins can change a category's rule. Everyone else can see the rules.
- The default organization's guardrails are fixed at the safe defaults.
Shadow mode
Shadow mode lets you try a policy before you enforce it. Rules are evaluated and logged but not enforced: actions run, and Activity shows which ones would have been blocked (Would block) or would have needed approval (Would ask first).
Owners and admins turn it on and off in Controls on the Guardrails page, with Enable shadow mode and Disable shadow mode. While it is on, the page shows a Shadow mode notice, with Enforce now to turn enforcement back on.
Emergency stop
Emergency stop blocks every write operation across the organization at once: changes, scaling, provisioning, deletion and messaging. Reads keep working, so Nova can still investigate while nothing changes. Nova still posts its own status, such as an investigation's card and updates in the alert thread or channel you set, and says the stop is on.
Owners and admins turn it on with Activate emergency stop in Controls on the Guardrails page, and off with Deactivate emergency stop or Resume. While it is on, a notice shows at the top of every page in Nova, with Resume for owners and admins.
Always on, whatever your rules
Two protections apply on top of your policy, and you cannot turn them off:
- Security floor. If a file Nova generated in the conversation, such as a Helm chart, Terraform module or manifest, has a critical security finding, Nova makes no changes in that conversation until it is fixed.
- Burst limit. Nova makes at most 10 write actions per minute in an organization. Past that, writes pause until the next minute, so a runaway loop cannot flood production. Messages count on their own budget of 10 a minute, so a burst of notifications never pauses a fix.
Every decision is recorded
Activity, on the Guardrails page, lists every decision: the action, its category, what it targeted, the outcome, and who approved it and when. Search it, filter by category, or filter by outcome:
| Filter | Shows |
|---|---|
| All decisions | Every decision |
| Approvals and blocks | Everything that did not simply run: approvals, denials, withheld reads and blocks |
| Allowed | Actions that ran under an Allowed rule |
| Asked first | Actions that paused for a decision |
| Withheld | Sensitive reads an investigation skipped because access was not granted |
| Approved | Actions someone approved |
| Denied | Actions someone denied, or that nobody answered before the deadline |
| Blocked | Actions a rule, emergency stop, the burst limit or the security floor blocked |
| Kept hidden | Notes, not decisions: a change that kept the current value of fields hidden from Nova |
- Everyone sees their own activity. Owners and admins see the whole organization and can open an entry's full trace.
- Export CSV downloads the activity as CSV.
- How long activity is kept depends on your plan: 24 hours on Free, 90 days on Enterprise.
Nova's activity records Nova's decisions. On the Enterprise plan, the platform's Audit Logs also record changes to your clusters, applications and organization, whoever makes them and however they are made, because every way in calls the same API. A change Nova makes is recorded under the member who asked for it.
Next
- Staying in control: how approvals, guardrails, audit and rollback fit together across AstroPulse.
- Rollback: undo an application change.
- Alerts: let Alertmanager or Grafana start investigations.