IPNS Sentinel: Monitoring and Controlling AI Agent Tool Calls
By Ashok Murthy, VP and CTO, IP Network Solutions
Why we built Sentinel
AI agents are increasingly able to use tools, delegate work, and coordinate with other agents. That creates an important question: when an agent moves beyond its assigned responsibilities, what mechanisms do we have to detect that behavior, alert an operator, and intervene before the next action?
I started Sentinel after reading about the OpenAI and Hugging Face incident. OpenAI’s account described models operating during internal evaluations communicating through unauthorized channels and taking actions outside their assigned tasks. It made the need for oversight of agent behavior very concrete.
Jev’s speed in making structured decisions was a primary reason for building Sentinel. I saw an opportunity to combine capable agents, including those powered by Claude or OpenAI models, with a separate, policy-aware monitor that examines proposed actions before execution.
What Sentinel does
IPNS Sentinel is an open-source developer preview that adds monitoring and controls around an existing Python agent’s tool execution.
It assesses a proposed tool call against operator-defined policy, recent actions and results, and available context about other agents. Developers can begin with observation and alerts, then use an enforcement wrapper to prevent a flagged tool call from executing. Sentinel also includes cross-agent correlation and signed audit records to support investigation.
One important goal is distinguishing legitimate coordination from unauthorized coordination. Agents collaborating through an approved channel should not be treated the same as agents creating their own communication channel outside the operator’s rules. Agents working independently on the same task should not be flagged simply because their activity looks similar.
Getting those distinctions right is a central part of what we want developers to test.
What you can try today
The public repository includes an offline quickstart, integration examples, and synthetic evaluation cases covering both policy violations and legitimate activity.
The offline demonstration requires no API keys or model account. It uses fixed test scoring to demonstrate how the monitoring and enforcement components connect. It makes no model calls and does not establish real-world detection accuracy.
Live testing is separate. Developers supply their own provider credentials, or use the evaluation runner with a supported, operator-approved self-hosted endpoint. No IPNS API keys or shared model accounts are included.
Where its coverage ends
Sentinel is experimental—not a production security guarantee.
Blocking applies only to tool calls routed through Sentinel’s enforcement wrapper. Unwrapped tools and direct host access remain outside its coverage. It is not a replacement for sandboxing, least-privilege access, or other security controls.
Its assessments depend on the actions and context made available to it, not access to an agent’s private reasoning. Detection quality, false alerts, and end-to-end latency require broader evaluation across models and deployments.
Help us test it
We are inviting developers to try Sentinel with synthetic data and share what works and what does not.
We particularly welcome feedback on false alerts, missed violations, integration difficulties, and latency. Small, reproducible examples are valuable; you do not need to run a large evaluation to contribute.
Explore IPNS Sentinel on GitHub · Report feedback
Please keep credentials and private data out of public reports. Security vulnerabilities should be reported through the repository’s private reporting process.