Skip to content

Security hardening proposal: safer defaults for hooks and trust boundaries #25

@its-DeFine

Description

@its-DeFine

Hi team — I reviewed the hook automation paths in arscontexta and found several places where secure defaults could be improved.

Important context: this report is about hardening and trust boundaries. It does not claim malicious intent.

Summary

Current behavior is convenient for trusted single-user workflows, but risky in adversarial or mixed-trust environments.

Findings

  1. Broad auto-staging + commit-hook bypass
  • hooks/scripts/auto-commit.sh uses git add -A and commits with --no-verify.
  • Risk: accidental staging of sensitive/unrelated files and bypass of local security hooks.
  1. Repo-local script execution from SessionStart
  • hooks/scripts/session-orient.sh runs bash ops/scripts/reconcile.sh --compact if present.
  • Risk: arbitrary repo-local execution surface at session start.
  1. Raw context injection into model context
  • session-orient.sh emits raw file content (self/goals.md, self/identity.md, etc.) directly into the conversation context.
  • Risk: prompt-injection-style instruction smuggling via vault content.
  1. Fail-open vault detection / marker auto-creation
  • hooks/scripts/vaultguard.sh auto-creates .arscontexta based on fallback checks.
  • Risk: hooks can activate in places where explicit opt-in was not intended.

Proposed hardening (minimal breakage)

  1. Add a security_mode config with default strict.
  2. In strict mode, replace git add -A with an allowlisted set of paths.
  3. In strict mode, disable --no-verify by default (allow explicit override).
  4. Gate reconcile.sh execution behind explicit opt-in (allow_reconcile_exec: false default).
  5. Treat loaded file content as untrusted data:
  • wrap in clear delimiters,
  • prepend non-instructional framing,
  • cap size per file.
  1. Require explicit marker presence for activation (no fallback auto-create in strict mode).
  2. Document this threat model in SECURITY.md (“trusted personal vault” vs “shared/untrusted repo”).

Why this helps

These changes preserve current UX for trusted workflows (compat mode) while giving security-conscious users a safer default profile.

If useful, I can open a PR with a backward-compatible strict/legacy toggle.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions