[ RUNTIME POLICY ENFORCEMENT ]
Policies enforced at call time. Not reviewed after.
SentnelOps intercepts every MCP tool call before the server sees it, evaluates it against plain-YAML policy, and permits, blocks, or pauses it for human approval — with under 15ms p99 overhead, inside your own VPC.
[ WHY REVIEW-AFTER-THE-FACT FAILS ]
Logs describe. They don't decide.
A dashboard that shows what an agent did yesterday cannot stop what it is doing right now. By the time a reviewer reads the log line, the table is dropped, the branch is force-pushed, the ticket is closed. Runtime policy enforcement for AI agents means the decision happens before the action, not after.
Agents don't wait for the retro.
AI agents chain dozens of MCP tool calls per minute across GitHub, AWS, Postgres, and internal APIs. Post-hoc review scales at human speed; agents operate at machine speed. The only control point that keeps up is one that sits in the call path itself.
Trust-by-default doesn't age well.
SentnelOps is zero trust by default: every agent starts with zero permissions, and you grant capabilities explicitly — per agent, per server, per condition. Nothing is implicitly allowed just because it worked last sprint.
[ WHAT A POLICY LOOKS LIKE ]
# policies/agents.yaml — illustrative
policies:
- name: block-destructive-db-tools
agent: deploy-bot
server: postgres
tools: [drop_table, truncate_table]
action: block
- name: gate-production-merges
agent: release-agent
server: github
tools: [merge_pull_request]
when: target_branch == "main"
action: require_approval # pauses → Slack DM → resume on approvalEvaluated on every call · < 15ms p99 proxy overhead · zero data egress
[ YAML, GITOPS, CI ]
Policies live in git
Rules are plain YAML files — version-controlled, code-reviewed, and rolled out through the same GitOps pipeline as the rest of your infrastructure. A policy change is a pull request, with a diff and a reviewer, not a click in a console.
Tested in CI before they ship
Because policies are files, they are CI-testable. Assert that the deploy agent can never call a destructive database tool, and let the pipeline fail if anyone loosens that rule. Your policy suite becomes a regression test for agent behavior.
Approvals where you already work
Any rule can use require_approval instead of block. The call pauses, a Slack DM arrives with the full context — agent identity, tool, parameters — and the agent resumes only after your explicit approval. Alerts also go out via Slack and email.
⟨ BLOCK VS REQUIRE_APPROVAL ⟩
block is for calls that should never happen: the request is rejected before the MCP server sees it, the agent receives a clear denial, and the decision is written to your call log — agent identity, tool name, parameters, timestamp, and the policy rule matched. require_approval is for calls that are sometimes legitimate: the call pauses, a Slack DM delivers the full context to a human, and the agent resumes only after explicit approval. Any rule can use either action, so the line between "never" and "ask first" is a one-word edit in YAML. Every decision — permitted, blocked, or approved — lands in the same audit trail, stored in your own database. See audit evidence for what gets captured, or how agent identity scopes every grant. The enforcement point itself is the SentnelOps MCP firewall, deployed in your VPC between your agents and your MCP servers.
Enforce your first policy in under 10 minutes.
Follow the quickstart and get your first MCP tool call logged in under 10 minutes. Scout is free; Sentnel Starter is $299/mo and Command Team is $799/mo — paid tiers start when you’re ready. Or see what your agents can actually do first — we run a 10-day governance assessment in your own VPC.