[REVIEW] secrets-management: add brokered agent credential and canary-token gates

[NiXouuuu]

Skill Being Reviewed

Skill name: secrets-management
Skill path: skills/devsecops/secrets-management/

False Positive Analysis

Benign canary token that can be incorrectly treated as a production secret leak:

secret_scan_finding:
  file: "infra/canary/aws-canary.tfvars"
  detected_type: "AWS_ACCESS_KEY"
  value_status: "live"
  owning_account: "111122223333"
  account_classification: "security-canary"
  alert_destination: "soc-webhook"
  production_privileges: false
  allowlist:
    reason: "approved honeytoken fleet"
    owner: "security-engineering"
    expires: "2026-09-30"

Why this is a false positive:

The skill correctly says known secret prefixes should generally be flagged, but it does not distinguish production credentials from intentionally deployed canary/honey tokens. Modern secret detection programs often use valid-looking tokens to alert on repository scraping or credential misuse. These tokens may be live in the sense that provider validation succeeds, but they are intentionally privilege-less and monitored.

The review should not simply suppress these findings forever, because attacker-created allowlists would be dangerous. The better behavior is to require ownership, account/project identity, no production privileges, alert routing, expiry, and periodic revalidation. A canary token with that evidence should be recorded as a control artifact, not scored as a critical leaked production secret.

Relevant public references:

• https://github.com/mongodb/kingfisher
• https://owasp.org/www-project-cheat-sheets/

Coverage Gaps

Missed variant 1: agent receives real provider credentials instead of brokered credentials

agent_runtime:
  name: "repo-maintenance-agent"
  prompt_sources:
    - "GitHub issue comments"
    - "repository files"
  outbound_targets:
    - "https://api.github.com"
    - "https://api.openai.com"
  injected_environment:
    GITHUB_TOKEN: "real token from secret store"
    OPENAI_API_KEY: "real provider key"
  egress_policy:
    allow_any_https: true

Why it should be caught:

Step 5 says agents should use short-lived tokens and JIT credentials, which is useful, but it still assumes the credential is delivered to the agent runtime. For LLM agents that process untrusted web pages, issue comments, repo files, or tool output, a short-lived real token can still be exfiltrated during its valid window.

The skill should add a stronger evidence gate for agentic systems: where possible, agents should receive scoped broker tokens, placeholder credentials, or per-tool capability handles, while a trusted broker/proxy injects the real upstream credential only at the network boundary. The report should distinguish "short-lived real secret in agent environment" from "brokered credential never visible to the agent."

Missed variant 2: credential broker has no host/path binding or egress deny policy

credential_broker:
  mode: "outbound proxy"
  agent_visible_token: "session-placeholder-token"
  upstream_secret: "github_pat_stored_server_side"
  injection_rules:
    - host: "*"
      path: "*"
      header: "Authorization"
  network_policy:
    default: "allow"

Why it should be caught:

Brokered credentials are only safer if the broker enforces where and how a secret can be used. A proxy that injects a GitHub token for any host or path can turn SSRF, DNS rebinding, or prompt-injection-driven browsing into credential misuse. The current skill mentions token scope, but it does not require broker evidence such as allowed host/path/method rules, default-deny egress, upstream IP deny lists, structured audit logs, and per-request identity.

Missed variant 3: live-validation scanners confirm secrets without preserving validation safety evidence

scanner_config:
  tool: "secret-scanner"
  live_validation: true
  validators:
    - "aws"
    - "github"
    - "slack"
  missing_evidence:
    - "validator only uses read-only identity checks"
    - "validator does not trigger provider side effects"
    - "validation logs redact values and account IDs"
    - "canary account IDs are explicitly classified"

Why it should be caught:

The skill discusses secret detection tools and false-positive filtering, but it does not address live validation. Live validation reduces noise by checking whether a token is active, but it can introduce operational and legal risk if validators call privileged APIs, trigger alerts without context, expose account identifiers, or mishandle canary credentials. The review should require evidence that validation is side-effect-limited, redacted, rate-limited, and separated from remediation actions.

Edge Cases

• Short-lived tokens are still exfiltratable: A 10-minute token can be enough for destructive API calls if it has broad scope and the agent can be prompt-injected.
• Broker outage fallback: If the fallback path injects raw provider secrets into the agent environment, the system regresses exactly when operators are under pressure.
• Canary token rotation: A stale canary with broken alert routing is no longer useful as a control and should not be silently allowlisted.
• Provider identity leaks: Some live validators reveal account, workspace, or organization identifiers even when they do not expose the secret value.
• Tool-specific capability handles: The safest implementation may not be a network proxy; it can also be a tool gateway that exposes narrow operations rather than raw credentials.

Remediation Quality

• Fix resolves the vulnerability
• Fix doesn't introduce new security issues
• Fix doesn't break functionality
• Issues found: The fix should expand Step 5 and the detection-tool review without weakening the existing hardcoded-secret guidance:
  • add an "agent credential exposure model" field: raw secret, short-lived real secret, brokered token, or capability handle;
  • require host/path/method binding and default-deny egress evidence for credential brokers;
  • require broker audit logs that identify agent, tool, upstream service, request class, and injected credential alias without logging secret values;
  • classify approved canary/honey tokens separately from production leaks, with owner, expiry, alert destination, and no-production-privilege evidence;
  • add live-validation safety checks for read-only validation, redaction, rate limiting, and provider side-effect control.

Comparison to Other Tools

Tool	Catches this?	Notes
Gitleaks / detect-secrets	Partial	They detect patterns and support allowlists/baselines, but they do not prove canary ownership, alert routing, or brokered runtime credential isolation.
TruffleHog / Kingfisher-style live validation	Partial	Live validation can confirm whether a credential works, but reviewer policy still needs to classify canaries and require safe validator behavior.
Vault / cloud secret managers	Partial	They store and rotate secrets, but they can still deliver raw secrets to an agent runtime unless paired with brokered access or capability-scoped tools.
Credential broker / agent-vault patterns	Yes	These reduce exfiltration risk by keeping real upstream credentials outside the agent runtime and injecting them at a trusted boundary.

Overall Assessment

Strengths:

The skill is strong for conventional repository and CI secrets hygiene. It covers common file discovery, secret pattern detection, false-positive filtering, .env exposure, git history scanning, vault/cloud secret managers, rotation automation, and agent-specific short-lived credentials.

Needs improvement:

The agent-specific section stops at short-lived/JIT credentials, which is necessary but not sufficient for agentic systems that process untrusted content. The central question is whether the agent can ever see or print the real credential. The skill also needs a safer model for canary tokens and live validation so security controls are not reported as production leaks or blindly allowlisted.

Priority recommendations:

1. Add a brokered-credential evidence gate for AI agents and automation bots, distinguishing raw secrets from broker tokens and capability handles.
2. Require broker policy evidence: host/path/method allowlists, default-deny egress, upstream IP deny lists, and per-request audit logs.
3. Add canary/honey token classification rules so approved monitored tokens are not scored as critical production leaks without control-context checks.
4. Add live-validation safety requirements for scanners, including redacted logs, read-only probes, rate limits, and side-effect review.
5. Make fallback handling explicit: broker outage procedures must not silently inject long-lived provider secrets into the agent runtime.

Bounty Info

• I have read and agree to the CONTRIBUTING.md bounty terms
• Preferred payment method: PayPal or crypto; I can provide payout details privately after acceptance.

[Peter7896]

/attempt #1160

I am taking a focused implementation pass on skills/devsecops/secrets-management/ for brokered agent credential evidence and canary-token handling. Scope: distinguish raw secrets, short-lived real secrets, broker tokens, and capability handles; require broker host/path/method/default-deny evidence and audit logs; classify approved honeytokens separately from production leaks with owner/expiry/alert routing/no-production-privilege evidence; and add live-validation scanner safety checks for read-only probes, redaction, rate limiting, and provider side-effect control.

Bounty target: Improver Moderate ($100) if accepted. Payment details can be provided privately after maintainer acceptance.

[Peter7896]

Implemented in #1179

This adds brokered agent credential and canary-token evidence to secrets-management: agent credential exposure model, credential broker host/path/method and default-deny checks, canary/honey token classification, live-validation scanner safety gates, output tables, severity updates, pitfalls, and version 1.0.2.

Validation performed:

• git diff --check (only existing Windows LF-to-CRLF warning)
• Markdown fence balance check (16, even)
• marker checks for canary/honey evidence, live validation, broker policy, default-deny egress, real-secret visibility, and changelog version