Security and platform engineers implementing their first enforceable agent policy.
How to control invoke_tool against resources observed during a reviewed shadow-mode period without blocking routine agent work.
The control gap
Observed-use recommendations need simulation and human review before they narrow production authority or remove an emergency path.
Generate the candidate list from a defined observation period and include evidence counts, last-seen timestamps, denied attempts, and the policy rule currently granting reach. Reviewers need to know whether the sample includes incident response, releases, monthly close, and other infrequent but legitimate operations.
Run simulation against captured requests before creating a draft. A passing simulation means the proposal preserves that sample, not that it is universally safe. Endram therefore leaves the recommendation in review, records who creates the draft, and relies on the existing policy publication workflow for enforcement.
Separate unused authority from unused integration. A tool may be connected for recovery but intentionally dormant, while another may be called daily against only one of hundreds of reachable resources. Review principal, action, resource, environment, task, and downstream credential scope independently so the recommendation names the actual excess.
Account for observation bias. Retention gaps, sampling, new deployments, seasonal finance work, and incident-only paths can all make legitimate capability appear unused. Display the evidence window and coverage beside every proposal, then ask the service owner to mark exceptional paths before simulation begins.
A review should produce a versioned draft, not mutate live rules. Compare old and proposed reach, simulate captured allow and deny cases, obtain the policy owner's approval, and retain rollback. After publication, monitor new denials and approval load; rollback should restore the prior version without deleting the failed experiment.
What good looks like
A narrow policy that can be tested in shadow mode, reviewed with owners, and promoted to enforcement with measurable impact.
- Match the concrete action "invoke_tool" rather than every operation exposed by the tool.
- Scope the target to resources observed during a reviewed shadow-mode period and the production environment.
- Require a request-bound approval that expires and cannot be reused.
- Record denied attempts as well as approved executions.
A production workflow
- Copy the template and replace example identities and resource selectors.
- Run it in shadow mode against representative requests.
- Review false positives, missing resource attributes, and approver routing.
- Enable enforcement for one agent and expand only after reviewing the decision log.
A policy you can test
AI agent least-privilege review policy is a concrete starting point, not a claim that one generic rule fits every environment. Replace example identities and selectors, validate the request shape, and begin in shadow mode.
name: agent-least-privilege-review
match:
identity_verified: true
agent_principal: ["agent_support"]
tool: github.create_issue
resource: ["repo:acme/support"]
decision: allowEndram keeps the policy version with every decision. A later change creates new evidence instead of rewriting why an earlier request was permitted.
Evidence to require
- Every attempted invoke_tool, including denied requests.
- The exact resources observed during a reviewed shadow-mode period selector evaluated by policy.
- The requesting agent, delegated user, reviewer, and timestamps.
- Policy version, matched rule, decision reason, and execution result.
Buyer checklist
- Does the selector cover only the intended production resources?
- Who owns the approval queue outside business hours?
- What is the acceptable approval expiry?
- Which emergency identity may bypass the rule, and how is that use audited?
Practical answers
Common implementation questions
Can I use this policy as written?
Use it as a reviewed starting point. Replace example identities, actions, and resource selectors, then validate it in shadow mode against your actual tool-call shape.
Why use approval instead of a permanent allow?
Approval preserves a low-friction path for exceptional work without turning a one-time need into standing access.
Does a denied call appear in the audit trail?
Yes. Denied and expired requests remain part of the decision log so control owners can tune policy and investigate attempted actions.