Writing policy at execution time, not deploy time
Access decisions baked in at deploy are stale by the time they matter. We evaluate the policy graph the moment an agent acts. Here is what that buys you.
Deploy-time policy is a photograph
When you decide access at deploy time, you freeze a picture of the world and hope it stays true. But sponsors change, agents get compromised, risk levels shift. By the time the agent acts, the photograph may be weeks old.
Execution-time policy asks the question when it actually matters: this agent, this action, this scope, right now. The answer reflects the current state of the graph, not the state at the last deploy.
Autonomy where it is safe, gates where it is not
Evaluating at execution time lets you grade decisions by risk. Low-risk grants run autonomously — the agent never waits on a human for something routine. High-risk grants, money and sensitive data and new external systems, escalate to the named sponsor.
The result is not a bottleneck. Most actions clear instantly. The few that should make a person pause actually do, and every decision — autonomous or gated — lands in an attestation-ready log.
- #policy
- #authorization
- #runtime
More field notes
Short-lived credentials, in practice
Everyone agrees keys should expire. Then someone sets the TTL to a year so nothing breaks. Here is how we make minutes-long credentials survive contact with real workloads.
Priya Nandakumar · Head of Platform
7 min read
Zero standing keys: a migration playbook
Getting to no long-lived secrets is a project, not a switch. This is the order we recommend, and the traps in each phase.
Priya Nandakumar · Head of Platform
9 min read