Write repeatable access and lifecycle requirements.
Policies API
The Policies API manages rules and bindings that shape privileged actions. This is where Security as Code becomes practical: access requirements, verification expectations, session controls, rotation posture, and review rules become repeatable control logic.
Typical Operations
Section titled “Typical Operations”- List policies and understand available control logic.
- Create or update policy definitions.
- Bind policies to resources or scopes.
- Review effective policy posture for a target resource.
- Keep policy changes explainable through logs and review workflows.
- Inspect resolved behavior to see the exact control values Anchor applies.
- Use dependency summaries before changing policies that govern sensitive resources.
Policy Controls
Section titled “Policy Controls”Anchor policies can express operational controls that security teams and engineers can both understand:
{ "verify_enabled": true, "verify_interval_days": 7, "rotate_enabled": true, "rotate_interval_days": 30, "secret_reveal_allowed": false, "secret_retrieval_allowed": false, "use_sudo": false, "allow_password_auth": true, "allow_key_auth": true, "key_rotation_enabled": true, "discover_unknown_keys": true, "allow_unknown_keys": false, "session": { "launchAllowed": true, "recordingRequired": true, "clipboardAllowed": false, "fileTransferAllowed": false, "sessionTimeoutSeconds": 3600, "idleTimeoutSeconds": 900, "launchTokenTtlSeconds": 60 }}The value is not the JSON itself. The value is that access policy, credential lifecycle, SSH posture, session governance, and audit expectations can be reviewed and automated as one control model.
Bindings and Inheritance
Section titled “Bindings and Inheritance”Policy bindings are where Security as Code becomes operational. A scope-level binding governs a whole operating boundary; a resource-level binding can tighten control for a sensitive target. Effective policy review tells teams which policy applies, and resolved behavior explains the control source, reason, warning, and override state.
Safety
Section titled “Safety”Automated policy changes are security-relevant. Use review workflows, narrow automation identities, and logs to keep changes explainable.
| Safety concern | Anchor posture |
|---|---|
| Broad policy automation | Use narrow API identities and keep policy changes reviewable. |
| Binding mistakes | Review dependency and effective-policy context before changing live controls. |
| Hidden drift | Keep policy changes tied to logs, review workflows, and resolved behavior. |