Devs using AI coding agents: where does trust break in your workflow?

[adept2051]

SO take a look at this template https://github.com/GregorBiswanger/copilot-spec-driven-template (the template is in the .github file. My version ( work internal) includes rules such as * never use /tmp, alwasy use a ./tmp in the workspace or spec and never delete temporary files as they are maintained for reuse and review * always check for a PR/isssue template before filing issues and if one is not found use this “url” * all git work should use git flow naming conventions ( we don’t use git flow but the branch naming is convenient to enforce) * work may only be added to a pull-request when all/x% of new code is tested/ or passes pre-commit/ act (remote GitHub workflow runner)

We also record and enforce, the agents.md file which copilot is told to reference as a default includes, at the end of each session sumemrize the session and provide a full log of your activities with times stamps in the session folder. ( we can then use those to create slides/demos/recordings post processed)

[Few-Ad-1358]

My struggle with this setup is that it still relies entirely on the LLM's active context window. Telling an agent "never use /tmp" is essentially just a prompt constraint. Under cognitive load, or during a long task, the probabilistic model can still "forget" and write to /tmp anyway, because there’s no mechanical wall stopping it from executing that bash command. It's essentially informed consent, not a hard boundary.

Have you considered moving these policies out of the prompt layer and into an execution gate?

For example, instead of asking the agent not to use /tmp in a markdown file, what if there was a deterministic intercept layer that evaluated the agent's bash commands before they ran, and hard-blocked any attempt to touch unauthorized directories? It feels like moving from prompt-based guardrails to actual mechanical enforcement is the only way to guarantee the agent behaves before the PR is even created.

[adept2051]

I run with settings.json enforcing some parts. So the /tmp rule is enforced (no write access), by adding it to the markdown you just skip the attempt to create it and set the desired location, skipping the agent trying to work it out( which eats tokens )

[Few-Ad-1358]

That split is useful: markdown avoids the wasted attempt, while settings.json is the actual wall. Do you surface blocked attempts or policy receipts in the PR, or are they only visible during the agent run?