Get startedSign in

Common policy use cases

Patterns for governing workbench tools and infrastructure stack approvals

Policies are most useful when they encode a narrow, explainable rule around a high-impact operation. Start with guardrails that can be evaluated from explicit input fields, then expand coverage as you observe real evaluations in the simulator.

Workbench policies

Extend authorization for external tools

Many external systems have coarse authorization models: a credential may allow access to an entire observability account, log index, or API even when a user only needs a subset. Workbench policies can add request-level controls without issuing a separate credential for every user and use case.

Examples include:

  • Restricting production log searches to an incident-response group
  • Denying queries against sensitive audit or customer-data indices
  • Limiting observability queries to approved accounts, services, or time ranges
  • Preventing write operations through an external API while permitting reads

Policy input includes both the actor and tool arguments, allowing the decision to account for who is requesting the action and exactly what the agent plans to send.

Increase autonomy with safe-action allowlists

Agents are most useful when routine, reversible actions can proceed without waiting for a human. Add approve rules for a well-defined set of safe operations while leaving everything else on the normal approval path.

Examples include: