Short description
An action-governance layer that checks an agent's proposed tool calls before execution, blocks prohibited actions, pauses selected actions for human review, and records decisions and outcomes.
Inspiration / Problem
AI agents can encounter useful content alongside untrusted instructions, then propose tool actions while carrying out a legitimate task. When authorization is implicit in conversational context, it can be difficult to inspect exactly what action is being requested, stop it before execution, involve an operator selectively, and later verify what happened.
What it does
ADR adds an independent decision point between an agent's proposed action and a tool's execution. It evaluates the proposed action against policy and produces one of three distinct outcomes: ALLOW for an authorized action, BLOCK for a prohibited action, or REQUIRE_APPROVAL when human review is required. An action awaiting review remains pending until the operator approves or rejects it. ADR records the policy decision, human decision, and tool outcome separately, so stopping one action is not confused with the status of the legitimate task.
The owner-approved hosted Judge Experience has six sections for an interactive walkthrough, selectable scenarios, policy decisions, human approval or rejection, and evidence. The current hosted experience uses deterministic ScriptedModel turns, fictional calendar and email data, and simulated tool effects. It makes no live Nebius or Nemotron requests.
How we built it
ADR combines a Python policy and workflow service, SQLite-backed audit evidence, an authenticated operator decision path, and an HTML/CSS/JavaScript Judge Experience. The system separates the agent's proposal, ADR's authorization decision, any human decision, and the simulated tool effect into traceable workflow events. Reproducible offline fixtures and tests support the current judge walkthrough.
The source also includes a separately guarded experimental Nebius Token Factory adapter for NVIDIA Nemotron. It is separate from the hosted scripted demo and from the original B1 protocol.
Challenges
The main challenge was preserving a verifiable link between the exact proposed action, its policy outcome, any human decision, and the resulting tool effect. A model proposal, an authorization decision, and an executed action are different events and need separate evidence. The project also keeps offline fixtures, transport tests, and historical provider records distinct.
Accomplishments
- An owner-approved, six-section hosted Judge Experience.
- An interactive policy workflow showing ALLOW, BLOCK, and REQUIRE_APPROVAL, including operator approval and rejection.
- A durable audit trail linking proposals, decisions, and simulated tool outcomes.
- Reproducible offline fixtures and evaluation materials.
- A public MIT-licensed source repository.
- Separately preserved exploratory Nebius/Nemotron integration records.
What we learned
A successful bounded provider round trip is useful integration evidence, but it does not prove that an attack induced an action or that a policy reduced attack success. Explicit provenance and task-status reporting are necessary to interpret successful and failed workflows. Human review is most useful when it is tied to the exact pending action and its arguments.
What's next
What's next
Next steps include expanding policy coverage, strengthening operator workflows, testing additional agent and tool integrations, and evaluating ADR against more diverse scenarios with reproducible evidence.
Future work will focus on measuring authorization behavior, human-review effectiveness, and task continuity under controlled conditions before making broader security or production-readiness claims.
Technologies and platforms
Python, SQLite, HTML, CSS, JavaScript, Nebius Token Factory, and NVIDIA Nemotron 3.5 Lightning. The hosted Judge Experience uses ScriptedModel; the experimental provider adapter and historical live records are separate. Nebius AI Cloud was not used. Nemotron was accessed through Nebius Token Factory in bounded historical exploratory runs.
Significant updates to a pre-existing project
ADR began as an experimental research codebase. During the hackathon period it gained an integrated action-governance workflow with a policy gate, authenticated human approval and rejection, audit evidence, workflow continuation handling, a six-section judge-facing application, reproducible offline fixtures, and a separately activated experimental Nebius/Nemotron adapter. The hosted demo remains scripted and offline so judges can explore without triggering provider calls.
Technical challenge / implementation notes
The policy gate is designed to evaluate a proposed tool action before it reaches the tool runtime. The hosted scenarios use fictional data and simulated effects. Historical provider traces are read-only evidence and are not replayed as new requests. Provider-side token counting and serialization are not certified.
Feedback for organizers and providers
Nebius Token Factory
The bounded exploratory requests returned responses usable by ADR's tool-call workflow. Reproducible agent evaluation would benefit from model or serving revision information and a documented pre-inference token-counting contract that covers tool schemas and the full conversation. Billing views would also benefit from clearly distinguishing per-request usage, aggregated usage, estimated cost, and invoiced cost. This feedback is based on a small exploratory sample, not a general provider assessment.
NVIDIA Nemotron
Nemotron 3.5 Lightning was usable in the bounded exploratory tool-call workflow through Token Factory. Versioned documentation of supported tool-call formats and serving/tokenizer behavior would help reproduce integrations. This is limited integration feedback, not a model-quality evaluation.
Nebius AI Cloud
Nebius AI Cloud was not used in this project; no first-hand product feedback is available.
Limitations and evidence boundaries
- B1: BLOCKED / verified:false. Nothing in this submission should be described as B1-certified.
- Current hosted demo: deterministic ScriptedModel, fictional calendar/email data, and simulated tools. It is not a live Nemotron session.
- Historical live evidence: separate, bounded exploratory Nebius Token Factory/NVIDIA Nemotron runs. The two-request
calendar_allowsmoke recorded a model-proposed calendar call, an ADR ALLOW decision, a fictional tool result in a follow-up request, and a final model response. The run had a known calendar-fixture date mismatch; it is not evidence of calendar accuracy. - A separate six-request exploratory workflow exercised fictional approval and rejection paths. These limited records do not establish B1 compliance, general prompt-injection resistance, causal protection, statistical superiority, or production readiness.
- Do not describe a scripted fixture as an action generated by Nemotron or the hosted demo as making live provider calls.
- Shared authentication is not a separate judge role. The password's reuse outside ADR is unknown; do not claim it is exclusive.
Log in or sign up for Devpost to join the conversation.