Agent policies, secrets, and custom probes

This page covers three related screens under Fleet: Agent Policies, Secret Injections, and Custom Probes. They’re grouped together in the app’s navigation, but each controls something different - read the headings below rather than assuming they’re variations on one setting.

Agent policies

Fleet → Agent Policies (/gravity/settings/agent-policies) controls how much autonomy automated and AI-driven actions are given within your organization. This is different from the per-agent capability grants described elsewhere in this section (those control what a specific fleet agent is allowed to be asked to do at all - patch scanning, remote exec, and so on); agent policies control how much an automated system is allowed to act on its own once something is being considered.

Each policy has:

• Scope - organization-wide, a specific environment (like prod or dev), or a specific action-type pattern
• Autonomy level:
  • L0 - Observe Only: read-only, no writes
  • L1 - Suggest Only: generates recommendations, a human executes them
  • L2 - Execute with Approval: can act, but requires human approval first
  • L3 - Auto-Execute: acts without approval, within the policy’s other limits - the app shows an explicit warning when you choose this level
• Freeze windows - recurring time windows (with days and a timezone) during which automated actions are always blocked, regardless of level, useful for a change freeze or a standing weekend blackout
• Max blast radius - the largest scope a single automated action is allowed to affect: a single resource, a service tier, an availability zone, or a region
• Blocked / allowed action types - an explicit list on top of the level

Safe defaults

Start new policies at L0 or L1 until you’ve reviewed what they’d actually do in practice. If you do use L2 or L3, pair it with a tight blast radius and at least one freeze window, rather than leaving it unconstrained.

Automated cloud provisioning checks these policies before an action proceeds.

Secret injections

Fleet → Secret Injections (/gravity/fleet/secret-injections) tracks delivery of secrets from your configured secret store to a service running on one of your fleet agents. Secret values are never stored in Sencai - only a reference to where the value lives in your secret store.

1. Click Add Injection.
2. Give it a Secret Name (a label, not the value), a Secret Reference (the path in your secret store holding the actual secret), the Target Service, and a delivery method: environment variable, file, or Kubernetes Secret.
3. Optionally scope it to one cloud instance.

Caution

The referenced secret store path must already hold the value - Sencai never writes to it. Triggering an injection here confirms the reference resolves in your secret store. End-to-end delivery of the secret to the target host is not complete, so this does not confirm the value reached the target service. Verify that manually before depending on this for a production secret rotation.

Revoking an injection marks it as revoked; the agent stops delivering it on its next cycle.

Custom probes

Fleet → Custom Probes (/gravity/fleet/probes) lets you define a check - an allow-listed binary plus arguments - that runs as root, on every enrolled agent in your organization, on a schedule you choose.

Caution

There is no per-agent targeting. Enabling a probe here means it runs on your entire fleet, not a single host you might have had in mind.

Only a fixed set of binaries can be used: docker, kubectl, systemctl, journalctl, cat (restricted to /etc/os-release), dpkg-query, and rpm. The exact command a probe will run is always shown before you save it - never hidden behind a label.

1. Click New probe.
2. Choose a binary and, if applicable, arguments.
3. Set a timeout and how often it runs.
4. Save.

Results - exit code, output, and when each run was collected - are listed per agent under Recent results, filterable by probe.

Caution

Apart from cat, which is pinned to /etc/os-release, only the binary is restricted - the arguments you give it aren’t. Most real checks with these binaries are read-only (systemctl status, docker inspect, journalctl -u), but nothing stops you from defining one that isn’t (systemctl restart, for example) - and it would then run, as root, on every enrolled agent in your organization on the schedule you set. Review the exact command shown before you save a probe, the same way you’d review a remote command before dispatching it.

Safe defaults

Prefer genuinely read-only commands, and start with a longer interval - a probe with a mutating command run fleet-wide is closer to a scheduled runbook than an inspection check. A probe failing or timing out on one host has no effect on any other host it runs on.

What’s next

• Fleet agent - the capability model these policies sit alongside
• Remote execution - commands and runbooks, gated the same way
• Agent releases - cohorts and staged rollouts
• AI governance - the related EU AI Act oversight controls