docs: add cognitive security manifesto and threat taxonomy v1#23637
docs: add cognitive security manifesto and threat taxonomy v1#23637BrianCLong wants to merge 2 commits intomainfrom
Conversation
Co-authored-by: BrianCLong <6404035+BrianCLong@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
WalkthroughThis pull request updates a GitHub Action reference to use a major version tag, adds two new cognitive security documentation files defining a manifesto and threat taxonomy, and updates the submit.json file structure with new fields. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
⚔️ Resolve merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Co-authored-by: BrianCLong <6404035+BrianCLong@users.noreply.github.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
docs/cognitive-security/threat-taxonomy-v1.md (1)
9-77: Add per-class detection and containment fields to improve incident response usability.Consider adding a compact section per class (Detection Signals, Required Evidence, Containment Action, Recovery Validation). It would make the taxonomy directly usable by SecOps/AI platform teams.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/cognitive-security/threat-taxonomy-v1.md` around lines 9 - 77, The document lacks per-class operational fields; add a compact subsection under each canonical class (Corrupted Cognition, Non-Compliant Cognition, Non-Reproducible Cognition, Non-Admissible Cognition) containing four standardized headings: Detection Signals, Required Evidence, Containment Action, and Recovery Validation, with 1–3 bullet-style lines each to keep entries concise and actionable for SecOps/AI platform teams. Ensure the new subsections follow the existing markdown style and formatting for each class so they appear directly under the Definition/Sub-types/Examples blocks and use consistent terminology across all four classes.docs/cognitive-security/manifesto.md (2)
35-43: Define key terms on first use to keep this artifact standalone.Terms like “Reality Graph,” “Quarantine Graph,” and “Epistemic Immune System” are central but currently implicit. Add brief inline definitions (or links to a glossary) to prevent interpretation drift.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/cognitive-security/manifesto.md` around lines 35 - 43, The document uses domain-specific terms without definitions—add concise inline definitions or glossary links for "Admissibility Gates", "Reality Graph", "Cognitive Security Protocol (CSP)", "Quarantine Graph", and "Epistemic Immune System" at their first occurrences so the manifesto is standalone; for example, append a parenthetical one-line definition or a bracketed link to a glossary entry after each term (e.g., Reality Graph (canonical, verifiable model of system state) and Quarantine Graph (isolated store of unverified cognitive packets)), and ensure the CSP is labeled as "Cognitive Security Protocol (CSP)" where first mentioned to introduce its abbreviation.
23-27: Make the three principles testable with explicit acceptance criteria.These are strong statements, but turning each into concrete MUST-level checks (input/output validation criteria, provenance requirements, graph consistency checks) will make the manifesto operationally enforceable.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@docs/cognitive-security/manifesto.md` around lines 23 - 27, The three principles ("Verification Before Execution", "Epistemic Integrity", and "Graph-Based Grounding") are high-level and need explicit, testable acceptance criteria; for each principle add a short MUST-level checklist of deterministic checks and measurable pass/fail conditions (e.g., for "Verification Before Execution" list input/output validation rules, required unit/integration tests, and explicit failure modes; for "Epistemic Integrity" specify required provenance fields, cryptographic/signing requirements, retention of lineage metadata and how to validate it; for "Graph-Based Grounding" define graph consistency invariants, allowed relation types, required graph validation procedures and test cases). Ensure each criterion is written as an acceptance test (Given/When/Then or clear boolean checks) so they are operationally enforceable and automatable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/ci-attest.yml:
- Line 30: Replace the mutable tag "actions/attest-build-provenance@v1" with a
fixed commit SHA to pin the action; locate the workflow step that contains the
uses entry "actions/attest-build-provenance@v1" and change it to
"actions/attest-build-provenance@<full-commit-sha>" (use the exact 40-char
commit SHA from the action's repo) so the attestation step is immutable and
reproducible.
In `@docs/cognitive-security/threat-taxonomy-v1.md`:
- Line 75: The term "WriteSet firewall" in the example sentence is undefined;
add a short inline definition or a parenthetical reference so readers understand
its role (e.g., "WriteSet firewall (a validation layer that rejects writes
missing required evidence IDs)") or link to the section that defines it; update
the sentence containing "WriteSet firewall" in the threat example and, if
appropriate, add a one-sentence glossary entry or a cross-reference to the
document section/class/term that defines WriteSet firewall.
---
Nitpick comments:
In `@docs/cognitive-security/manifesto.md`:
- Around line 35-43: The document uses domain-specific terms without
definitions—add concise inline definitions or glossary links for "Admissibility
Gates", "Reality Graph", "Cognitive Security Protocol (CSP)", "Quarantine
Graph", and "Epistemic Immune System" at their first occurrences so the
manifesto is standalone; for example, append a parenthetical one-line definition
or a bracketed link to a glossary entry after each term (e.g., Reality Graph
(canonical, verifiable model of system state) and Quarantine Graph (isolated
store of unverified cognitive packets)), and ensure the CSP is labeled as
"Cognitive Security Protocol (CSP)" where first mentioned to introduce its
abbreviation.
- Around line 23-27: The three principles ("Verification Before Execution",
"Epistemic Integrity", and "Graph-Based Grounding") are high-level and need
explicit, testable acceptance criteria; for each principle add a short
MUST-level checklist of deterministic checks and measurable pass/fail conditions
(e.g., for "Verification Before Execution" list input/output validation rules,
required unit/integration tests, and explicit failure modes; for "Epistemic
Integrity" specify required provenance fields, cryptographic/signing
requirements, retention of lineage metadata and how to validate it; for
"Graph-Based Grounding" define graph consistency invariants, allowed relation
types, required graph validation procedures and test cases). Ensure each
criterion is written as an acceptance test (Given/When/Then or clear boolean
checks) so they are operationally enforceable and automatable.
In `@docs/cognitive-security/threat-taxonomy-v1.md`:
- Around line 9-77: The document lacks per-class operational fields; add a
compact subsection under each canonical class (Corrupted Cognition,
Non-Compliant Cognition, Non-Reproducible Cognition, Non-Admissible Cognition)
containing four standardized headings: Detection Signals, Required Evidence,
Containment Action, and Recovery Validation, with 1–3 bullet-style lines each to
keep entries concise and actionable for SecOps/AI platform teams. Ensure the new
subsections follow the existing markdown style and formatting for each class so
they appear directly under the Definition/Sub-types/Examples blocks and use
consistent terminology across all four classes.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ac3d4a9b-5197-4ce5-917d-c68798ce31a4
⛔ Files ignored due to path filters (1)
pnpm-lock.yamlis excluded by!**/pnpm-lock.yaml
📒 Files selected for processing (4)
.github/workflows/ci-attest.ymldocs/cognitive-security/manifesto.mddocs/cognitive-security/threat-taxonomy-v1.mdsubmit.json
|
|
||
| - name: Generate build provenance attestation | ||
| uses: actions/attest-build-provenance@6f6ed36d4dbaea10032f2447f91f6f24e6f1d64c | ||
| uses: actions/attest-build-provenance@v1 |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "All action refs in workflows:"
fd -e yml -e yaml .github/workflows | while read -r file; do
echo "== ${file} =="
rg -n '^\s*uses:\s*[^@]+@.+$' "$file"
done
echo
echo "Potentially non-immutable refs (not pinned to 40-char SHA):"
fd -e yml -e yaml .github/workflows | xargs rg -nP '^\s*uses:\s*[^@]+@(?![0-9a-f]{40}\b).+$' || trueRepository: BrianCLong/summit
Length of output: 481
🏁 Script executed:
cd .github/workflows && find . -type f \( -name "*.yml" -o -name "*.yaml" \) -print0 | xargs -0 -I {} sh -c 'echo "=== {} ===" && cat -n "{}"' | head -100Repository: BrianCLong/summit
Length of output: 3520
🏁 Script executed:
# Check the specific file and line 30
cat -n .github/workflows/ci-attest.yml | sed -n '25,35p'Repository: BrianCLong/summit
Length of output: 439
🏁 Script executed:
# List all action refs in workflow files with proper syntax
fd . .github/workflows --extension yml --extension yaml -x rg -n '^\s*uses:\s*' {}Repository: BrianCLong/summit
Length of output: 50373
🏁 Script executed:
# Check for non-SHA pinned actions (looking for patterns like `@v1`, `@latest`, `@main`, etc.)
fd . .github/workflows --extension yml --extension yaml -x rg -nP 'uses:\s+[^@]+@(?![0-9a-f]{40}\b)' {}Repository: BrianCLong/summit
Length of output: 50373
Pin the attestation action to an immutable commit SHA (not @v1).
On Line 30, using a moving tag allows unreviewed upstream changes to alter provenance behavior over time. For this security-sensitive step, pin to a full commit SHA.
Suggested fix
- uses: actions/attest-build-provenance@v1
+ uses: actions/attest-build-provenance@<full_40_char_commit_sha>🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/ci-attest.yml at line 30, Replace the mutable tag
"actions/attest-build-provenance@v1" with a fixed commit SHA to pin the action;
locate the workflow step that contains the uses entry
"actions/attest-build-provenance@v1" and change it to
"actions/attest-build-provenance@<full-commit-sha>" (use the exact 40-char
commit SHA from the action's repo) so the attestation step is immutable and
reproducible.
|
|
||
| **Examples:** | ||
|
|
||
| * An agent outputs a JSON response missing a required evidence ID field, causing the data to be rejected by the WriteSet firewall. |
There was a problem hiding this comment.
Undefined control term: WriteSet firewall.
WriteSet firewall appears without a definition in this document. Add a short definition or reference so the example is interpretable without external context.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@docs/cognitive-security/threat-taxonomy-v1.md` at line 75, The term "WriteSet
firewall" in the example sentence is undefined; add a short inline definition or
a parenthetical reference so readers understand its role (e.g., "WriteSet
firewall (a validation layer that rejects writes missing required evidence
IDs)") or link to the section that defines it; update the sentence containing
"WriteSet firewall" in the threat example and, if appropriate, add a
one-sentence glossary entry or a cross-reference to the document
section/class/term that defines WriteSet firewall.
Core category documents for Summit Cognitive's GTM positioning. Extracted from #23637 (docs-only, skipping lockfile/workflow changes that had conflicts). - docs/cognitive-security/manifesto.md: Category thesis, core sentence, paradigm shift argument (admissibility over alignment), CSP/quarantine/ subsumption pillars. v1.0.0 draft. - docs/cognitive-security/threat-taxonomy-v1.md: Structured threat taxonomy for cognitive security failures (stochastic drift, prompt injection, epistemic poisoning, context hijacking, etc.) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Docs-only extraction from #23637. Skipped lockfile/workflow changes that conflicted. Adds the foundational category documents for Summit Cognitive GTM positioning. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Gemini CLI <gemini-cli@google.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This pull request implements the initial drafts of the Cognitive Security Manifesto and Threat Taxonomy v1 as standalone, publishable artifacts in the
/docs/cognitive-security/directory.The manifesto covers the Category Thesis, Core Category Sentence, the shift from probabilistic alignment to deterministic admissibility, and the Messaging Hierarchy. The Threat Taxonomy v1 outlines the four Canonical Failure classes: Corrupted Cognition, Non-Compliant Cognition, Non-Reproducible Cognition, and Non-Admissible Cognition, with definitions, subtypes, and examples for each.
PR created automatically by Jules for task 5346770267403756260 started by @BrianCLong
Summary by CodeRabbit