Skill Being Reviewed
Skill name: privileged-access
Skill path: skills/identity/privileged-access/
False Positive Analysis
Benign automation pattern that can be over-reported if every PAM API token is treated as unmanaged standing privilege:
automation_identity: deploy-secret-broker
purpose: issue short-lived database credentials to production deploy jobs
auth_method: OIDC/JWT to Vault, no static token in CI variables
policies:
- read-only path for one application namespace
- no token creation except child tokens with bounded TTL
controls:
ttl: 15m
max_ttl: 1h
audit_device: enabled
token_accessor_logged: true
owner: platform-security
rotation_or_rebuild: on pipeline identity change
Why this should not be a finding by itself:
The current skill correctly warns about CI/CD secrets, admin-scope API keys, vault access policies, and ephemeral credentials. However, a reviewer still needs a specific evidence model for automation identities that call the PAM/vault platform itself. A tightly scoped workload identity with short TTL, namespace-limited policies, audit logging, and no static secret has a materially different risk profile from a long-lived bearer token or AppRole SecretID stored in a pipeline variable.
Without that distinction, reports can either overstate risk for mature machine-to-PAM integrations or understate risk for automation accounts that effectively have privileged credential broker authority.
Coverage Gaps
Missed variant 1: PAM control-plane API token is broader than the job it supports
ci_job: rotate one app password
pam_api_identity:
token_scope: admin / all safes / all secrets
ttl: 90 days
stored_in: CI variable
audit: only API login events, no per-secret read/rotate correlation
Why it should be caught:
The skill inventories privileged service accounts and admin-scope API keys, but it does not require reviewers to connect each automation identity to the PAM actions it can perform: secret read, checkout, rotate, account onboarding, safe/admin management, session launch, token creation, policy changes, or audit export. A token that can administer the vault or retrieve many privileged credentials is not just another stored secret; it is a privileged broker identity.
Missed variant 2: AppRole / client credential bootstrap creates a secret-zero problem
auth_method: Vault AppRole
role_id: baked into image
secret_id: stored in GitHub Actions secret
secret_id_ttl: unlimited
secret_id_num_uses: unlimited
token_ttl: 24h
Why it should be caught:
HashiCorp documents AppRole as a machine authentication method and recommends patterns that limit blast radius and duration. If both bootstrap factors are static, broadly distributed, unlimited-use, or unwrapped, the pipeline can become the new standing privileged account even though the downstream database credentials are dynamic.
Missed variant 3: connector/service identity can change PAM policy or audit evidence
connector: pam-sync-bot
permissions:
- create accounts
- update rotation policies
- disable audit forwarding
- export safes
owner: shared mailbox
last_review: unknown
Why it should be caught:
PAM tools depend on connectors, sync jobs, APIs, and service accounts for discovery, rotation, ticketing, SIEM forwarding, and cloud integrations. If those identities can weaken rotation policy, add new accounts, retrieve secrets, or tamper with audit forwarding, they deserve the same least-privilege and session/evidence scrutiny as human administrators.
Missed variant 4: token expiry exists but revocation and residual child tokens are not reviewed
parent token revoked after incident
unknown:
- child tokens minted before revocation
- leases created by the token
- active sessions started through the broker
- audit records proving no post-revocation secret reads
Why it should be caught:
The skill has strong JIT and revocation language for human privileged sessions, but automation identities can mint tokens, leases, or broker sessions that survive differently depending on product behavior and token hierarchy. Reviewers should record TTL, max TTL, renewable/periodic behavior, child-token capability, lease ownership, revocation path, and post-revocation validation evidence.
Edge Cases
- Some automation identities legitimately need privileged API permissions for rotation, discovery, or break-glass workflows; those should have a named owner, narrow target set, bounded TTL, strong bootstrap path, and audit correlation.
- Vaulted API tokens are still standing privilege if the token itself is long-lived and can retrieve or administer broad privileged credentials.
- AppRole can be acceptable when SecretID delivery, wrapping, TTL, use count, CIDR constraints, and policy scope are controlled; the review should not simply flag the word
AppRole.
- OIDC/JWT workload federation reduces stored-secret exposure, but reviewers still need to verify claim scoping, token audience, policy mapping, and downstream vault/PAM permissions.
- SIEM forwarding identities can become high impact if they can disable audit export, delete evidence, or change event routing.
Remediation Quality
Recommended evidence table:
| Field |
Required evidence |
| Automation identity |
name, owner, platform, business purpose |
| Auth/bootstrap method |
OIDC/JWT, AppRole, client credential, API key, certificate, managed identity |
| Secret-zero handling |
static/rotated/wrapped/federated, TTL, use count, storage location |
| PAM/vault permissions |
secret read, checkout, rotate, admin, policy change, account onboarding, audit export |
| Scope boundary |
safe/project/path/namespace/account set, environment, tenant |
| Token controls |
TTL, max TTL, renewable/periodic, child-token creation, lease behavior |
| Audit evidence |
token accessor/client ID, target secret/account, action, ticket/job ID, SIEM forwarding |
| Revocation evidence |
revoke path, child token/lease/session cleanup, post-revocation validation |
| Confidence |
strong / partial / docs-only / not evaluable |
Comparison to Other Tools
| Tool / Framework |
Catches this? |
Notes |
| HashiCorp Vault AppRole / token controls |
Partial |
Supports TTLs, policies, response wrapping, and token hierarchy, but the skill should require these fields in PAM review output. |
| CyberArk / Delinea / BeyondTrust API integrations |
Partial |
PAM products expose API automation paths; reviewers still need to prove the integration identity is scoped and audited. |
| SAST / secret scanning |
Partial |
Can find hardcoded tokens, but cannot prove API scope, vault policy, token TTL, or child-token behavior. |
Current privileged-access skill |
Partial |
Mentions CI/CD credentials, API keys, vault policies, and dynamic secrets, but does not treat PAM automation identities as first-class privileged principals. |
Overall Assessment
Strengths:
- Strong coverage of privileged inventory, PAM tool maturity, JIT, break-glass, session recording, vaulting, and PAM bypass.
- Good warnings that service accounts and admin-scope API keys can be privileged.
- Useful guidance around ephemeral and dynamic credentials.
Needs improvement:
- Automation identities that call the PAM/vault API should be inventoried separately from the secrets they retrieve.
- The output should record bootstrap/secret-zero evidence, token TTL/max TTL, child-token and lease behavior, scope boundaries, and audit correlation.
- Reports should distinguish a mature federated workload identity from a static long-lived bearer token stored in CI.
- Revocation validation should include residual child tokens, leases, brokered sessions, and post-revocation activity checks.
Priority recommendations:
- Add a PAM automation identity/API-token evidence gate after the PAM tool assessment or vaulting section.
- Add finding IDs for broad PAM API token scope, static secret-zero bootstrap, missing token TTL/use-count controls, missing audit correlation, and incomplete token/lease revocation.
- Add benign and vulnerable examples for OIDC-to-vault, AppRole with wrapped short-lived SecretID, and long-lived CI API token with broad vault admin rights.
- Add
Not Evaluable reasons for missing token policy export, unknown TTL/max TTL, missing audit export, unknown child-token behavior, and unverified revocation path.
Sources Checked
Bounty Info
Note: I created this through the GitHub API, so if the template labels are not applied automatically, please tag this with review / bounty if eligible under CONTRIBUTING.md.
Skill Being Reviewed
Skill name:
privileged-accessSkill path:
skills/identity/privileged-access/False Positive Analysis
Benign automation pattern that can be over-reported if every PAM API token is treated as unmanaged standing privilege:
Why this should not be a finding by itself:
The current skill correctly warns about CI/CD secrets, admin-scope API keys, vault access policies, and ephemeral credentials. However, a reviewer still needs a specific evidence model for automation identities that call the PAM/vault platform itself. A tightly scoped workload identity with short TTL, namespace-limited policies, audit logging, and no static secret has a materially different risk profile from a long-lived bearer token or AppRole SecretID stored in a pipeline variable.
Without that distinction, reports can either overstate risk for mature machine-to-PAM integrations or understate risk for automation accounts that effectively have privileged credential broker authority.
Coverage Gaps
Missed variant 1: PAM control-plane API token is broader than the job it supports
Why it should be caught:
The skill inventories privileged service accounts and admin-scope API keys, but it does not require reviewers to connect each automation identity to the PAM actions it can perform: secret read, checkout, rotate, account onboarding, safe/admin management, session launch, token creation, policy changes, or audit export. A token that can administer the vault or retrieve many privileged credentials is not just another stored secret; it is a privileged broker identity.
Missed variant 2: AppRole / client credential bootstrap creates a secret-zero problem
Why it should be caught:
HashiCorp documents AppRole as a machine authentication method and recommends patterns that limit blast radius and duration. If both bootstrap factors are static, broadly distributed, unlimited-use, or unwrapped, the pipeline can become the new standing privileged account even though the downstream database credentials are dynamic.
Missed variant 3: connector/service identity can change PAM policy or audit evidence
Why it should be caught:
PAM tools depend on connectors, sync jobs, APIs, and service accounts for discovery, rotation, ticketing, SIEM forwarding, and cloud integrations. If those identities can weaken rotation policy, add new accounts, retrieve secrets, or tamper with audit forwarding, they deserve the same least-privilege and session/evidence scrutiny as human administrators.
Missed variant 4: token expiry exists but revocation and residual child tokens are not reviewed
Why it should be caught:
The skill has strong JIT and revocation language for human privileged sessions, but automation identities can mint tokens, leases, or broker sessions that survive differently depending on product behavior and token hierarchy. Reviewers should record TTL, max TTL, renewable/periodic behavior, child-token capability, lease ownership, revocation path, and post-revocation validation evidence.
Edge Cases
AppRole.Remediation Quality
PAM Automation Identity and API Token Evidencegate. The current skill mentions service accounts, API keys, CI/CD credentials, and vault policies, but it does not require a structured review of identities that operate the PAM/vault control plane itself.Recommended evidence table:
Comparison to Other Tools
privileged-accessskillOverall Assessment
Strengths:
Needs improvement:
Priority recommendations:
Not Evaluablereasons for missing token policy export, unknown TTL/max TTL, missing audit export, unknown child-token behavior, and unverified revocation path.Sources Checked
Bounty Info
Note: I created this through the GitHub API, so if the template labels are not applied automatically, please tag this with
review/bountyif eligible under CONTRIBUTING.md.