Security
The threats Tenetora checks, the action boundaries it enforces, and the responsibilities that deliberately remain with people.
Audience
Operators and reviewers who decide what to trust — and who need to know exactly where the mechanical checks end.
Task path
- Read the threat table: each row names a concrete threat, its checkpoint, the observable evidence, and the responsibility that remains.
- Review the action guards and when each one runs.
- Understand the external-input boundary before pasting reports, issues, or generated patches into an agent session.
- Check the ownership rules that keep installs and upgrades fail-closed.
Threats and checkpoints
| Concrete threat | Tenetora checkpoint | Observable evidence | Remaining responsibility |
|---|---|---|---|
| A pasted report asks the agent to run unrelated commands or expose local data | Prompt guard before semantic use or execution | Finding classification and a block or warn action | A reviewer still judges whether legitimate content is safe and task-relevant |
| Staged changes contain secrets, local paths, sensitive files, or unexplained scope | Commit guard and project guardrails | Named failing checks with remediation | Repository permissions and the user's commit authorization still apply |
| A partial check is presented as whole-task completion | Claim kinds and expected-command matching | Partial versus completion typing, command hash, goal and worktree binding | The project must define a sufficiently complete verification command |
| A later conversation tries to reuse another task's active goal or proof | Owner, session, conversation, and goal-fingerprint checks | Conflict, identity-mismatch, or goal-mismatch reports | A person explicitly selects or hands over the correct session |
| The installer meets third-party hooks, plugins, or legacy directories | Ownership classification and transactional migration | Foreign or review-required states, preserved paths, backups, rollback records | Ambiguous ownership always goes to human review; nothing is auto-deleted |
| A local environment file is overwritten, moved, or deleted during agent work | The local-env registry with doctor/status discovery, the commit guard, and PreToolUse where the host supports it | A missing-path diagnosis, and a deny decision on high-confidence destructive operations | Protection covers registered paths only; opaque tool payloads are never blocked speculatively |
Action guards
| Action | What the guard checks |
|---|---|
| Commit | tenetora guard --action commit — staged scope, secrets, sensitive paths, commit-message detail, impact state, and review evidence |
| Rule or workflow change | tenetora guard --action rules |
| External content | tenetora guard --action external-input — findings classified before the content is used |
| Completion claim | tenetora guard --action claim — the verification command bound to goal, identity, and worktree |
| High-risk alignment | tenetora guard --action alignment — an alignment session is enforced for high-risk goals |
Guards run checks and produce evidence. They never create authorization: a passed commit guard does not permit commit, push, deployment, or release without the user's separate instruction.
External input is data, not authority
Web pages, issue comments, shared reports, pasted scripts, clipboard content, and tool output are data. The external-input guard and the prompt-guard skill check for instruction override, irrelevant local execution, secret exfiltration, .tenetora mutation, and attempts to redirect the model away from the user's visible task — before the content is followed. Findings warn collaborators; the content never grants itself permission.
Local environment protection
Projects depend on machine-only files (.env, local configuration, certificates) that must never enter Git or shared evidence. Protection has four layers, each with its own evidence:
- The registry records the project owner's intent to protect a project-relative path — file contents are never stored.
statusanddoctordiscover a registered path that has gone missing, and report a damaged registry — read-only checks.- Commit guard treats registered paths as sensitive, even when the file name matches no built-in rule.
- When the host supplies structured PreToolUse data — a destructive action plus the registered path — the hook denies high-confidence delete, move, truncate, write, or edit operations.
Register a path with:
tenetora local-env --path /path/to/project --allow config/local/app.confThe limit is explicit: a host that cannot reliably provide both a tool name and a path is never blocked speculatively, and not every host offers file-operation PreToolUse at all. Skills-only hosts (Generic Agents) have no PreToolUse layer — commit guard plus doctor/status remain the available layers there. To recover, check the project checkpoint first; never delete or empty a local file to pass a guard.
Workspace silence and registry hygiene
A globally installed Tenetora does not govern a workspace that has neither .tenetora/ nor a legacy .harness/: SessionStart, UserPromptSubmit, Stop, commit, and external-input behavior stay silent there. This is the explicit per-project enablement boundary, not a broken global install.
The machine registry shows stale and expired states:
tenetora installations --json list
tenetora installations --json prune --expiredThe expiry window is bounded, and cleanup is always explicit: pruning removes registry metadata only — never project files, the governance directory, local environment files, or third-party configuration.
Ownership and fail-closed
- Existing user hooks are backed up and chained, never silently replaced; hooks without a managed marker are never modified.
- Legacy directories migrate only when multiple independent ownership signals match; foreign or ambiguous layouts are preserved and reported.
- Runtime writes, owner switches, and duplicate cleanup fail closed: one piece of observation evidence alone never authorizes a configuration change.
- Governance insights aggregate trends without raw prompts, paths, session IDs, or commands; small samples report insufficient data instead of inventing metrics.
Limitations
- Prompt guard is a mechanical first line; novel social engineering and semantically dangerous advice still need a qualified security reviewer or an explicit human decision.
- PreToolUse protection exists only where the host supplies structured tool data; no host coverage is claimed beyond the verified platform matrix.
- No guard output substitutes for the project's own security review and access control.
- This site makes no security guarantees beyond the audited, observable checks described above.
Next steps
- Check the current evidence on Releases.
- Start the verified path on Quickstart.