Skip to content
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
75 changes: 75 additions & 0 deletions governance/cogsec/human-simulation-guardrail.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,75 @@
# Cognitive Security Human Simulation Guardrail
# Governs collection and model-building activities involving identifiable persons.

policy_id: COGSEC-HUMAN-SIM-001
status: active
Comment on lines +4 to +5
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Enforce the new active guardrail in CI policy checks

This policy is declared active, but the cogsec gate script (ci/scripts/cogsec_rights_gate.py) only requires the older four governance files and does not reference this new guardrail, so CI will not fail if it is removed or bypassed. That leaves COGSEC-HUMAN-SIM-001 as a non-enforced artifact rather than a guaranteed control. Add it to required policy checks or a runtime loader assertion.

Useful? React with 👍 / 👎.

owner: governance
last_reviewed: "2026-03-31"

scope:
applies_to:
- osint_connectors
- ingestion_pipelines
- model_training_jobs
- agentic_persona_tools

prohibited:
- id: no_persona_clone_without_authority
rule: "deny"
when:
target_type: identifiable_person
activity:
- persona_simulation
- predictive_vote_or_behavior_model
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

Splitting combined activity types into separate list items ensures that the policy engine can match against individual activity tags accurately. Using a single string like predictive_vote_or_behavior_model might fail if the system logs these as distinct activities (e.g., just predictive_vote).

        - predictive_vote
        - behavior_model

authority_basis:
not_in:
- statutory_authority
- explicit_written_consent
rationale: "Do not build human digital twins from public traces without legal authority or consent."

- id: no_unbounded_public_record_scrape
rule: "deny"
when:
collection_mode: scrape
evidence_budget:
missing: true
Comment on lines +34 to +35
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Deny unbounded scrapes when budget is present but invalid

The no_unbounded_public_record_scrape rule only denies when evidence_budget is missing, so a scrape with a present-but-unbounded budget can still pass despite the rule’s stated intent. In practice this allows effectively unlimited human-targeted collection as long as the field exists. Add an explicit boundedness check (for example max scope/limit constraints) instead of only a presence check.

Useful? React with 👍 / 👎.

rationale: "All human-targeted collection requires bounded scope and explicit evidence budget."

required_controls:
- id: require_case_binding
rule: "allow_only_if"
condition:
case_id: present
lawful_purpose: present
retention_policy_id: present
Comment on lines +42 to +44
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

high

The use of present as a value suggests a literal string match, which would cause the control to fail for any actual case ID or purpose string (e.g., 'CASE-123'). Given that line 35 uses the { missing: true } object syntax for existence checks, these should likely be updated to check for the presence of the field rather than a literal string value to ensure the guardrail functions correctly with real data.

      case_id: { missing: false }
      lawful_purpose: { missing: false }
      retention_policy_id: { missing: false }


- id: require_human_oversight
rule: "allow_only_if"
condition:
reviewer_role: governance_agent_or_human_dri
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

If the intention is to allow either the governance_agent or the human_dri to perform the review, it is better to define these as a list. This avoids potential string-matching issues and adheres to standard YAML policy patterns where roles are discrete entities rather than concatenated strings.

      reviewer_role:
        - governance_agent
        - human_dri

review_outcome: approved
Comment on lines +49 to +50
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P1 Badge Require human-only approval for simulation decisions

require_human_oversight currently allows reviewer_role: governance_agent_or_human_dri, which means an automated agent can approve human-simulation activity. For this high-risk path, that creates a policy-compliant route without a named human decision-maker, conflicting with the repo’s human-approval governance requirements for critical decisions. Tighten this control to require explicit human approver identity.

Useful? React with 👍 / 👎.


- id: require_observability
rule: "allow_only_if"
condition:
audit_log_fields:
- case_id
- prompt_hash
- policy_version
- decision_trace_id

governed_exception:
allowed: true
process: "Document in DecisionLedger + legal sign-off before execution."
expiry_days: 30

rollback:
trigger:
- policy_violation_detected
- missing_case_binding
- consent_revoked
actions:
- suspend_collection_job
- quarantine_artifacts
- open_redress_ticket
- notify_governance
10 changes: 10 additions & 0 deletions governance/cogsec/redress_process.md
Original file line number Diff line number Diff line change
Expand Up @@ -22,3 +22,13 @@ Applies to any automated or manual action that results in:

## 4. Logging
All appeals and outcomes must be logged in the `Governance Evidence Pack` (`EVD-COGSEC-GOV-001`).


## 5. Human Simulation Appeals (COGSEC-HUMAN-SIM-001)
If a person asserts the platform built or used a behavioral/persona simulation without authority:
1. **Immediate Freeze**: Suspend the associated collection/model job within 24 hours.
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

There is a contradiction between the term Immediate Freeze and the within 24 hours timeframe. For cognitive security incidents involving unauthorized human simulation, a 24-hour window may be too long for a response labeled as 'immediate'. Consider shortening this timeframe to reflect the urgency of the redress path.

Suggested change
1. **Immediate Freeze**: Suspend the associated collection/model job within 24 hours.
1. **Immediate Freeze**: Suspend the associated collection/model job immediately (e.g., within 1 hour).

2. **Authority Check**: Verify statutory authority or explicit written consent tied to the case.
3. **Artifact Quarantine**: Move related datasets/models into quarantine pending review.
4. **Outcome**:
* **Authorized**: Reinstate only with Governance sign-off and updated evidence trail.
* **Unauthorized**: Delete artifacts, record a DecisionLedger entry, and issue written remediation.
Loading