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: