Suppression strategy

Sebastion gives you three different ways to silence a finding. They are not interchangeable. Each one has a different scope, a different trust model and a different operational cost. This playbook is the decision tree for picking the right one.

The decision tree

Is this finding a false positive on one specific (rule, file)?
├── Yes, and it is medium / low / info severity.
│   ├── On the inline comment, reply: @sebastionai ignore <reason>
│   └── Done. Sebastion writes a Learning. Next audit on that file skips that rule.
│
└── Yes, and it is critical or high severity.
    └── Contact support. Chat-path suppression of critical/high is intentionally blocked.

Is this a rule that produces false positives across many files in a known scope?
├── Yes, and the scope follows a path (e.g. "scripts/ uses console.log on purpose").
│   ├── In AGENTS.md (top-level or in the directory):
│   │   # sebastion: ignore <rule_id> in <glob>
│   └── This creates a Learning the next time the base branch is updated.
│
└── Yes, and the scope is the whole repo.
    └── In .sebastionai.yml at the repo root:
        disable_rules:
          - <rule_id>

The three mechanisms in detail

1. disable_rules in .sebastionai.yml

Use when: the rule does not apply to your codebase at all, or applies in a way that is not useful given your stack.

Lives in: .sebastionai.yml at the root of the repo, read from the default branch.

Scope: every file, every path, every PR, for the whole repo.

Trust: committed to the repo like any other policy file. Reviewed on the PR that adds it.

Operational cost: very low. Edit YAML, open PR, merge.

disable_rules:
  - missing-helmet
  - generic-high-entropy

This is the right tool when, for example, you don't use Helmet because you serve every response through Cloudflare with its own security headers, and the missing-helmet rule will fire on every new Express handler. Disable it once at the policy level rather than ignoring it 40 times.

Do not use this for situations where a rule is right most of the time and wrong sometimes. That's what the other two mechanisms are for.

2. # sebastion: ignore <rule_id> in <glob> in agent files

Use when: a rule is right for the codebase in general but wrong for a specific path or directory.

Lives in: any of these four files (Sebastion reads all of them):

• AGENTS.md
• CLAUDE.md
• .cursorrules
• .github/copilot-instructions.md

Scope: path-scoped. A marker in a top-level AGENTS.md matches the glob across the whole repo; a marker in a nested file (e.g. bin/AGENTS.md) is scoped to that directory and below.

Trust: read only from the base branch. A PR that adds a marker has no effect until that PR is merged. This is deliberate — without it, an attacker could open a PR adding both an attack and a marker to suppress the audit of the attack on the same PR.

Operational cost: low. The same files your other agentic tools (Cursor, Claude Code, Copilot CLI) already read.

# sebastion: ignore py.print-statement in bin/**
# sebastion: ignore js.console-log in scripts/*.js

This is the right tool for path-scoped exceptions that are tied to the file's purpose rather than to organisational policy. The distinction matters: disable_rules says "we as an org don't care about this rule"; the marker says "this rule is fine in general, just not in this part of the codebase".

Because markers read from the base branch only, they also create an audit trail: every suppression is in git log, attributable to a reviewer who approved the PR that added it. There is no path for a single contributor to silently expand the suppression set.

3. @sebastionai ignore on an inline finding comment

Use when: you have a specific finding on a specific line that is a clear false positive and you want to silence just that.

Lives in: the GitHub comment thread on the finding itself.

Scope: the exact (rule_id, file_path) of the finding.

Trust: requires the commenter to have write permission on the repo. Bot accounts cannot create Learnings. The chat path absolutely cannot suppress critical or high severity findings — those require an operator-added Learning with an audit trail and an alert to our on-call engineer.

Operational cost: zero. Reply directly on the finding comment.

@sebastionai ignore false positive — input is sanitised in middleware

The free-text reason is optional but recommended. It is recorded in your tenant event log (not in the suppression store itself, to keep the store free of unstructured data — see data minimisation).

Rate limits apply: 20 new Learnings per hour, 100 per day, 500 active per installation. If you hit these, you are almost certainly better served by promoting recurring suppressions into AGENTS.md markers or disable_rules.

Worked examples

"Our bin/ directory uses print statements on purpose"

Wrong tool: disable_rules: [py.print-statement] — this turns off the rule for the whole repo, including the production code where you probably do want to know about stray prints.

Right tool: AGENTS.md marker.

# sebastion: ignore py.print-statement in bin/**

"We don't use Helmet because Cloudflare adds security headers"

Wrong tool: AGENTS.md marker scoped to ** — the auto-detect parser rejects bare wildcards exactly because they are equivalent to a repo-wide disable, and the operator path was designed to gate that case.

Right tool: disable_rules in .sebastionai.yml. This is an org-level policy, not a path-scoped exception.

disable_rules:
  - missing-helmet

"Sebastion flagged dangerouslySetInnerHTML in our Markdown renderer but we sanitise upstream"

Wrong tool: a blanket disable_rules entry for the rule — you absolutely do want this rule firing on the next person who reaches for dangerouslySetInnerHTML in a less considered context.

Right tool: @sebastionai ignore on the specific finding, with a reason that points at the sanitisation layer.

@sebastionai ignore — content is DOMPurified in lib/markdown/sanitize.ts before reaching this render path

If the same false positive starts repeating across multiple files in a known directory (say lib/markdown/**), promote it to an AGENTS.md marker so future contributors don't have to re-suppress.

Rules to live by

1. Default to the smallest scope that fixes the problem. Chat command beats marker beats disable_rules. Reach for the broader tool only when the narrower one would clearly create busywork.
2. Markers in agent files are the workhorse. They are path-scoped, base-branch-trusted, version-controlled and visible to your other AI tools. Most suppressions belong here.
3. Suppression is documentation. A # sebastion: ignore marker tells the next engineer (human or otherwise) "this rule is muted here for a reason". Treat it like any other piece of intent in the repo. Add a comment explaining why.
4. Review your suppressions quarterly. See learnings hygiene.

Related

• False positives and Learnings — the full security model behind every suppression mechanism.
• .sebastionai.yml reference — exact key types and defaults.
• Learnings hygiene — keeping your suppression set healthy over time.