Governed AI development workstations
One idempotent install that gives every workstation the same governed AI setup, with credential blocking and redacted audit that fail closed and a verifier that attacks its own controls.
Problem
Teams adopting AI coding assistants give software agents the power to write files and run shell commands. Credentials can end up in files, command lines or logs without anyone noticing. Each assistant vendor keeps its own configuration, so rules drift between tools and between people. And a developer working for several clients risks one client's tool connections loading into another client's work.
Goal
One idempotent install that gives every workstation the same governed setup, with controls that fail safe and a built-in way to prove that they work.
My role
Sole designer and author of the workstation kit: installer, hooks, settings merge, session launcher, verifier, templates and onboarding documentation. Also wrote a reusable report-design command for the assistant.
Solution
A workstation installer that builds a standard workspace, points several AI coding assistants at one shared rules file, registers hooks that run before and after each action, merges credential deny rules into existing settings, and ships a client-scoped session launcher and an adversarial verifier.
A small report-design command that turns structured data into a responsive single-file HTML report from a token-based component set, with optional PDF export.
How it works
The idempotent installer creates the folder skeleton, project and client templates, and one shared rules file that several assistant vendors read through links, so there is a single source of truth. Settings are merged into each engineer's existing configuration, never overwritten.
Every file write, edit and shell command an assistant proposes passes a hook that runs before the action, scans for credential-shaped content and blocks it. If the hook's own parser is unavailable, it blocks rather than allows: it fails closed.
A post-action hook appends every action to an audit log with secret-shaped strings redacted. Deny rules stop assistants reading credential files, and real secrets live in the operating system keychain, entered at a hidden prompt.
A session launcher starts work only inside a client folder that carries its own rules and tool-connection configuration, so one client's connections never load in another client's session.
The verifier attacks each control: it plants a fake credential, passes one inline on a command, simulates a broken interpreter, confirms that ordinary writes still work and that the hooks are registered, checks disk encryption, and prints a pass or fail compliance report.
Separately, the report command defines design tokens as CSS variables and a small component catalogue (header, stat cards, status cards, badges, bar charts, tables, grids), then renders gathered data into one self-contained HTML file, opens it and optionally exports a PDF through a headless browser.
Technical challenges
Detecting credentials in file content and shell commands without blocking normal work.
Making a guard fail closed when its own dependency breaks: a guard that silently allows everything is worse than none.
Redacting audit logs without destroying their usefulness.
Merging into existing settings safely and repeatably, so a second run changes nothing.
One rules file that several vendors' assistants all read.
Proving compliance by attacking the controls rather than by checking that files exist.
Isolating per-client tool connections, given how assistants discover their configuration.
Capabilities
- One-step governed workstation setup
- Credential blocking on file writes and shell commands
- Fail-closed hooks
- Redacted audit trail
- Credential-file deny rules
- One rules file across assistant vendors
- Per-client isolation of tool connections
- Adversarial self-test with a compliance report
- Keychain and disk-encryption checks
- Design-token report generation with PDF export
Technology
Impact
AI coding safety went from a written policy to enforced, verifiable controls installed the same way on every workstation, with a repeatable check that proves each control fires and clean separation between clients. No metrics are claimed.
Skills demonstrated
- AI tooling governance
- Secure-by-default and fail-closed design
- Adversarial testing of one's own controls
- Developer environment automation
- Multi-tenant isolation
- Audit logging with redaction
- Design systems for generated reports
Demo
PlannedA short terminal recording on a throwaway synthetic workstation: an assistant tries to write a file containing an obviously fake key ("FAKE_TOKEN_DO_NOT_USE") and the hook blocks it; an inline command carrying a fake key is blocked; an ordinary write is allowed; the audit log shows the redacted entry; the verifier plants its own fake credential, simulates a missing interpreter to show the fail-closed block and prints an all-pass report; a second run with one hook switched off reports FAIL. Two fictional folders, "client-alpha" and "client-beta", each load only their own tool connections. Beside it, a layered diagram of hooks, deny rules, audit log and client isolation. Built fresh with placeholder names.
Not built yet. A demo here uses only invented names and data.