Did your deny-by-default permission model hold in production?

[olijboyd]

A design question from outside the model-supply-chain world, so apologies if the tracker isn't the right home for it, and I'm happy to take it to the OpenSSF Slack instead if that fits better.

We're drafting a manifest format called tome.yaml that bundles AI instruction files (CLAUDE.md, AGENTS.md, .cursorrules, SKILL.md skills) into one portable unit with a lockfile and a security block. The security block declares what the bundle is allowed to do (read files, network, exec, secrets), denies by default, and if you omit the block entirely you get deny-all.

The thing we can't work out from theory is whether a strict default actually holds once authors are under real pressure to ship, or whether it quietly erodes into people pasting the minimum permission stanza needed to silence the validator without ever thinking about it. You've shipped deny-by-default at the model-supply-chain layer for longer than we have, so this is a community whose experience I'd trust over our own guesses.

So I'd appreciate hearing whether the strict default actually held in production, when in the lifecycle pressure to relax it first appeared, and what kept declarations deliberate rather than reflexive: lint, review, public visibility of what was being granted, something else, or simply nothing because it just worked out.

Two sentences of real experience would be massively appreciated. The full request for comment with three other open questions is collected here: tomevault-io/companyos#1, and the spec is at https://tomevault.io/docs/tome-yaml.

[mihaimaruseac]

Deny by default with a human maintainer in the loop for break-glass is the most suitable option, I think.

Failing open would enable an attacker to cause a failure at the same time as pushing a malicious model that would fail the signature verification.

[olijboyd]

Thanks, that's what I was hoping a signing project would give, and the failure you describe is exactly the one that made us switch to deny-by-default in the first place.

The break-glass step is the part I'm still unsure about. Holding the strict default at the spec level is easy enough; the harder question is the human in the loop you mentioned. When a maintainer does override and grant a capability, where does that override live so it remains visible and auditable later, rather than becoming a quiet edit? And have you found in practice that recording the break-glass as a signed, diffable event, so a reviewer sees "this component now asks for network or exec" as an explicit change, is enough? Or does the pressure simply migrate up a level with people starting to rubber-stamp the diffs instead?

What I'm most worried about is not that the default is too strict, but that adoption pressure erodes it through the escape hatch. I'd rather design the hatch to leave evidence than pretend nobody will use it.

[mihaimaruseac]

Infrastructure as code + gittuf, or some logging system that is monitored.

[olijboyd]

That's the pointer I was missing, thanks. Policy as code I had, gittuf I'd somehow not looked at, and it has the leave-evidence property I was fumbling towards: if the grant itself lives in the repo and the policy layer carries its own signed history, the break-glass override stops being a quiet edit and becomes an attributable change that something can watch. Rubber-stamping doesn't disappear, but it moves from invisible to monitorable, which is probably the honest ceiling for any escape hatch.

So that's the shape we'll write into the next draft: grants live in the manifest as code, every relaxation is a diffable signed event, and which logging system watches it stays a deployment concern rather than a spec concern. Thanks for taking the time on both answers, this thread gave me exactly what I came for.