Show HN: Control Layer Demo for AI Coding Agents

Letting coding agents (such as Claude Code) work autonomously on repos on a daily-basis, brings a high level of uncertainty. For those who won't let the agent decide alone whether it can create/modify or delete any folder on their repos; I wanted to be able to trace actions performed and being able to let the agent continue his work autonomously, or ask him to request a human approval according to some criteria defined. After investigations, the cleanest way to do it was according to me to develop a deterministic control layer between the LLM and the work of the agent that would track and catch potential non-respect of pre-defined rules. How? by first setting up approval rules (Pass/requires approval/refused) before the work of the agent, and afterwards controlling cryptographic SHA 256 verifications, etc. This allows to compare the before-after work of the agent. I have put in my public GitHub repo a demo that you can launch easily and observe different scenarios behaviors like applied authorized modification, protected file waiting for Human approval, or outside perimeter authorization modification refused. The demo is offline, does not involve the official runtime, in native node.js and without dependencies. It should still allow you to understand the core principles. I would like to know: how do you implement and handle safety boundaries? Especially if you let agents work on critical data/sensitive codebases? With which guardrails? Comments URL: https://news.ycombinator.com/item?id=50422833 Points: 1 # Comments: 0

Offline demonstration — simulated agent, simplified demo runtime. Proprietary Mintigate Runtime not executed. This folder is a small, deterministic demonstration that you can read in full and run on your own computer. A simulated agent proposes three fixed changes to a synthetic two-file fixture. A simplified demo runtime decides on each change in a temporary copy of the fixture, and an independent check confirms what happened. What it shows Each decision is recorded with the SHA-256 of the target before and after, in a report. What you need This folder, as received. Node.js 18 or later. Nothing else: no package to install, no Git, no Claude Code, no SDK, no network access, no account and no model call. Open a terminal in this folder (on Windows, PowerShell or Windows Terminal) and run: node mintigate-demo.mjs The demo takes no option. There is no live mode. Exit codes What it writes Each run creates a new folder .output/run--/ in this folder. Earlier runs are never changed. The fixture is copied into workspace/ inside that new folder, and the changes are made there only. The shipped fixture/ folder is never written. At the end of the run, even after an error, the demo removes the files and folders of that workspace/ one by one. It removes nothing else. What remains is one report: .output/run--/report.json. It holds the decisions, the audit records, the hashes, the checks, the negative controls, the clean-up count and the hashes of the demo files that were used. It contains no absolute path of your computer. Nothing is written outside .output/, and no setting of your computer is changed. To remove everything, delete this folder. How the checks work smoke-test.mjs does not use demo-runtime.mjs to judge the outcome. It copies the fixture, reads the files itself, computes their hashes and compares them with the expectations in scenarios.json: the decision of each scenario; for the applied change: exactly the expected line changed, and nothing else; for the other two: the target is unchanged, or was not created; the hashes in each audit record match the files; every protected file and every file outside the scope is unchanged, no file was created or deleted, the shipped fixture is unchanged, and the temporary copy was removed. It then runs negative controls: deliberately wrong expectations or observations, such as expecting the refused change to be applied or pretending that the protected file changed. Each one must make a named check fail. If a contradiction went unnoticed, the run ends with code 1. The agent is simulated: its three proposals are fixed in scenarios.json. No model is called. The runtime is a simplified demo runtime of a few rules: a folder or file scope, a list of protected files, and exact text replacements. It is not the proprietary Mintigate Runtime, which this demo does not contain or execute. The demo works only on its own synthetic fixture. It does not run on your repository, does not watch or intercept your tools, and has no approval command. It is not a benchmark and measures no performance. The MIT licence in LICENSE applies to the files of this kit only. Try a deliberate mismatch In a separate copy of the demo, open scenarios.json. For protected-file-change, change expect.decision from PENDING_APPROVAL to APPLIED, then run: node mintigate-demo.mjs The demo should exit with code 1: the protected change still requires approval, and the independent check rejects your altered expectation. Inspect the generated report.json to see the decision, failed checks, and file hashes. You control this local demo and can change its policies or code. It illustrates governance rules; it does not protect against its own administrator. Beyond the demo This demo illustrates scoped changes, human approval boundaries, and audit records using a deterministic agent and a simplified runtime. Mintigate is being developed to help developers govern real agent workflows. This demo does not execute its proprietary Runtime or connect to a live model. Explore the project, current evaluation results, and limitations: https://mintigate.com

出典

原文を読む ↗

出典

関連テーマ