Permissions deep-dive

The high-level pitch lives on the permissions page and in the Features grid. This page is for buyers and security teams who want to understand the scopes and the auditing.

What “smart defaults” actually means

Vibetight ships sensible defaults for what an agent can do without asking, and what it has to ask about. The line we draw is:

• Safe by default: read-only operations inside the working directory (listing files, reading their contents, running tooling that doesn’t mutate state).
• Asks every time: anything that mutates state, escapes the working directory, talks to the network in a way that could exfiltrate, or invokes a shell command whose side-effects aren’t obviously contained.

The exact shape of “safe” is the part we don’t document publicly. It’s the product of careful threat modeling, both to keep agents productive on benign work and to make sure the prompts you DO see are the ones that genuinely warrant your judgment. Documenting the recipe in detail would tell adversaries exactly which patterns slip past the default. So we don’t.

What we will commit to:

• We do not ship a “skip every permission prompt” flag, no matter how power-user you are.
• We do not ship a “pre-approve every shell command” mode. Too broad to be safe.
• We do not widen defaults silently. Any change to what’s auto-allowed is announced in release notes.

Scopes available today

When you Allow a prompt, you can choose how broad that Allow should be. The available scopes:

• Allow once. Just this one tool call. The next identical call asks again. The default for any prompt that genuinely warrants human judgment.
• Allow for this task. Every matching call inside the task that raised the prompt. Lifetime ends with the task.
• Allow always (this project). Every matching call in this project, on this and future tasks. Useful for project-specific tooling you’ve already vetted (a custom build script, a deploy helper).

There is no “allow everywhere forever” option. Allow rules are always anchored to a specific tool + specific argument shape + specific scope. The deny path is always available too, and a Deny is informative to the agent (it adapts), not punitive.

What a permission decision record looks like

When a prompt is answered (by you or by an Allow rule), the record persists with:

• Task: the specific task the prompt was raised on.
• Tool: the name of the tool the agent wanted to invoke.
• Input: the exact input the model produced (full text, structured arguments, file paths).
• Decision: Allow or Deny.
• Decider: the human who clicked the button, or the rule that auto-approved.
• Timestamp: when the decision was recorded.

These records are part of the audit trail. You read them back inside the task’s conversation pane: the full tool input is shown inline alongside the decision, no toggle required. They’re included in the GDPR data export.

When the default safe-policy auto-allows a read-only action, the record shows the default policy as the approver rather than a human. The audit export distinguishes the two cleanly, so you can review exactly what was approved without a human in the loop.

What happens on Deny

The agent receives the denial as a tool-call result (not a crash), and decides how to recover, usually by trying a different approach or asking the user for clarification. A Deny is informative to the agent, not punitive; it’s how you steer behavior without taking the agent offline.

If you need to fully stop a task, use the Stop action on the card. That’s a different kind of event, audited separately from permission decisions.

Where this is going: fleet-scale governance

Individual permission prompts are now a solved problem; every credible agent runner ships them. The interesting work, and where Vibetight’s substrate gives us an unfair advantage, is organisation-scale governance. Specifically:

• Tenant-wide policy. A security officer writes “no agent in this organisation may run rm -rf, push to main, or touch a path matching prod-*” once, and every agent across every device in the tenant inherits it. No more per-developer settings.json drift.
• Per-agent personas. Each agent identity (Vibetight models agents as first-class users with their own identity) carries its own policy envelope. “The migrations agent can touch /db/ and nothing else.” “The docs agent can read everywhere but writes only inside /docs/.”
• Time windows. “Defer any production deploy until 02:00 Europe/Amsterdam.” “Block risky actions outside business hours.” Agents that hit those rules queue the action and continue with other work.
• Approver routing. “An Allow on a prod-tagged action must come from a project maintainer, not just anyone with task access.” The web UI gates the Allow/Deny buttons by role.
• First-class audit. Every decision (human-clicked or policy-applied) lands in a tenant-wide audit log, filterable by agent, project, action, effect, and time range. Exportable to JSON or CSV for SOC2 / customer-trust artefacts.

This isn’t a wishlist; it’s the natural next layer on top of the substrate we already have (agents as identities, tenants and projects as a real org graph, cross-device prompt routing). Other agent runners would need to rebuild their model from the ground up to express these things.

What we say publicly about the policy model is what you can express; the matching grammar, evaluator internals, and rule storage shape stay internal. The capability is the pitch, not the recipe.

See also

• Permission prompts: the high-level pitch
• Audit trail: where decision records live and how to read them
• Security: high-level security posture