Tahr Security

View saved version →

---
name: tahr-audit-android
description: Audit Android application security from an APK, AAB-derived APK, Android source repository, manifest, or authorized emulator/device. Use for mobile release reviews, OWASP MASVS-oriented assessments, exported component and deep-link testing, WebView and IPC review, local storage and token analysis, mobile API traffic review, runtime instrumentation, privacy testing, and Android hardening validation.
---

# Tahr Audit Android

Use an artifact-first workflow to turn manifest and code signals into focused runtime checks. Keep static evidence, runtime reachability, and verified security impact distinct.

## Set scope and safety

1. Identify the application ID, build variant, APK hash, source revision, device profile, identities, and backend environment in scope.
2. Treat a local repository or supplied artifact as authorized for read-only review. Default to static analysis when active device or backend testing is not clearly authorized.
3. Use a disposable emulator snapshot, test install, test accounts, and synthetic data for state-changing checks.
4. Do not clear package data, change protected account credentials, trigger lockouts, submit real payments, send messages, write through content providers, load persistent code, or tamper with production data.
5. Do not modify the app or implement fixes unless the user explicitly asks.

Use secrets, tokens, PII, keys, cookies, and credentials only transiently for authorized verification. Persist their class, source, key or field name, redacted excerpt, length, fingerprint, scope, expiry, and replay result—not raw values.

## Inventory before testing

Read [attack-surface.md](references/attack-surface.md) before exploring the application.

Prefer existing artifacts over broad rescans: manifest, decompiled source, smali/resources, class or string index, static findings, device information, traffic capture, dynamic plan, and earlier coverage. If no compact index exists, create a focused inventory of URLs, secrets, crypto APIs, log calls, password/token fields, WebViews, JavaScript bridges, dynamic loading, and native libraries.

Build a target list with provenance for:

- exported activities, services, receivers, providers, and their permissions;
- deep links, app links, intent actions, URI authorities, and parameters;
- WebViews, loaded origins, settings, file/content access, and bridges;
- authentication, biometric, token, OAuth, and session paths;
- storage locations, backup behavior, logs, clipboard, and caches;
- crypto operations, keys, IVs, RNG, signing, and integrity decisions;
- endpoints, trust configuration, cleartext paths, pinning, and PII flows;
- deserialization, reflection, commands, dynamic code, native libraries, and dependencies;
- privacy permissions, tracking SDKs, consent states, retention, and screenshots.

## Separate evidence levels

Classify each observation immediately:

1. **Static candidate** — source, smali, manifest, resource, dependency, or configuration evidence identifies a plausible weakness.
2. **Runtime reachability** — adb, UI, proxy, logcat, filesystem, Frida, or backend evidence shows that the path executes or is externally callable.
3. **Verified impact** — the behavior crosses a confidentiality, integrity, authorization, authentication, privacy, or protected-functionality boundary.

Never label a static flag as runtime exploitation. An exported component, weak algorithm, permissive WebView setting, cleartext allowance, dependency CVE, or disabled resilience control is a target until the matching proof gate is met.

## Plan and run focused checks

Read [proof-gates.md](references/proof-gates.md) before dynamic testing or severity assignment.

Prioritize high-impact targets from artifacts. For each target, define the safe command or interaction, caller and app state, expected secure behavior, impact proof, cleanup, and stop condition. Exercise fresh, logged-in, proxied, unproxied, and offline states only when t

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-audit-secrets-config
description: Audit application-owned secrets, cryptography, dependency reachability, infrastructure-as-code, containers, CI/CD, cloud permissions, and runtime security configuration with evidence and false-positive controls. Use for repository hardening, deployment review, leaked-key triage, dependency/CVE review, exposed debug or admin surface checks, or pre-release configuration audits.
---

# Tahr Audit Secrets and Config

Find configuration and supply-chain weaknesses that become real attacker capabilities. Do not turn a keyword, permissive development setting, or package advisory into a vulnerability without proving production relevance and reachability.

## Establish scope and safety

Inspect source, committed configuration, lockfiles, build files, IaC, containers, CI/CD, and documentation read-only by default. Inspect git history only when the user includes it. Do not search unrelated home directories, credential stores, or `.git` working metadata.

Never validate a discovered credential against a live provider unless the user explicitly authorizes that exact action and the account is disposable. Never print, copy, commit, or persist a raw secret. Record type, file and line, source, scope, length, a short redacted preview, and a SHA-256 fingerprint.

Read [references/config-audit-matrix.md](references/config-audit-matrix.md) for the audit families. Read [references/exploitability-research.md](references/exploitability-research.md) before using advisory or CVE information.

## Inventory every configuration plane

Enumerate:

- application config and environment loading, including defaults and fallbacks;
- secret-manager, KMS, key-vault, certificate, and signing-key integrations;
- manifests and lockfiles for production, development, plugins, images, actions, and build tools;
- Dockerfiles, compose files, Kubernetes, Helm, Terraform, Pulumi, CloudFormation, Ansible, systemd, IIS, reverse proxies, and serverless definitions;
- CI workflows, release jobs, artifact publishing, package registries, caches, and deployment scripts;
- browser/mobile public configuration, source maps, runtime config endpoints, health, metrics, debug, admin, docs, and actuator surfaces;
- logging, telemetry, backups, data exports, error handling, and crash artifacts.

Mark generated, vendored, example, fixture, test-only, local-only, and production-relevant paths. Missing deployment material is a coverage gap, not proof of secure deployment.

## Review secret exposure

Search provider-specific formats and contextual assignments for cloud keys, OAuth clients, signing/session/webhook secrets, database and queue URLs, private keys, developer tokens, payment keys, AI provider keys, backup credentials, and privileged API keys.

For each hit:

1. Determine whether it is application-owned committed content, committed history, generated output, a placeholder, documentation, test fixture, environment reference, secret-manager lookup, public browser key, or local checkout metadata.
2. Exclude `.git/config`, remote URLs, hooks, logs, and scanner checkout credentials from application findings. A secret genuinely committed in repository history remains in scope.
3. Determine the exposure path: shipped client bundle, public artifact, image layer, CI log, repository audience, runtime endpoint, backup, or developer-only file.
4. Determine likely privilege, environment, restrictions, rotation status, and blast radius without using the raw value.
5. Inspect whether the application fails closed when the secret is absent or falls back to a default, empty, or hardcoded value.
6. Classify the result as `verified`, `static-confirmed`, `candidate`, or `rejected` with exact reasons.

Do not report environment-variable references or vault lookups as hardcoded secrets. Treat public client identifiers and publishable keys according to provider design; require missing restrictions or privileged use before claiming impact.

## Review producti

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-map-attack-surface
description: Map the real security-relevant surface of a web application or API from source, specifications, JavaScript, browser behavior, and authorized traffic. Use for pre-pentest reconnaissance, security-review scoping, hidden route or parameter discovery, undocumented API inventory, role-aware surface comparison, or judging whether an existing review actually covered the application.
---

# Map the Attack Surface

Build an evidence-backed inventory before testing vulnerabilities. Treat every discovered item as coverage evidence, not as a finding.

## Set the boundary

1. Identify the repository roots, application origins, API origins, environments, and supplied specifications or traffic captures.
2. Record the allowed runtime scope. Do not contact a live target unless the user supplied it or clearly authorized testing it.
3. Default to source-only analysis when authorization, credentials, or a runnable environment are absent.
4. Keep runtime activity read-only and low volume. Do not submit destructive forms, create real orders, send invitations, modify accounts, or enumerate unrelated infrastructure.
5. Never print or persist passwords, cookies, bearer tokens, API keys, reset links, private keys, CSRF values, or user PII. Retain names, locations, value classes, lengths, and short SHA-256 fingerprints when useful.

## Inventory independent evidence sources

Inspect each available source independently before merging:

- server routes, controllers, RPC handlers, middleware, authorization declarations, background jobs, queues, and WebSocket/SSE handlers;
- OpenAPI, Swagger, GraphQL schemas and documents, generated clients, protobufs, and API examples;
- frontend routes, forms, fetch/axios clients, lazy chunks, source maps, feature flags, upload configuration, storage keys, and custom headers;
- infrastructure routes, reverse-proxy rules, serverless functions, storage buckets, callback handlers, and public documentation;
- authorized unauthenticated and authenticated browser/API traffic, separated by identity, role, and tenant.

Do not infer reachability from a route name alone. Mark each operation as source-derived, documented, browser-observed, traffic-observed, or runtime-confirmed.

## Build canonical operations

Read [surface-inventory.md](references/surface-inventory.md) and create one record per meaningful operation. Preserve:

- protocol, origin, method or operation type, path, content type, and request shape;
- query, path, body, header, cookie, form, multipart, and GraphQL variable fields;
- authentication state, identity/role/tenant context, object identifiers, owner hints, and workflow state;
- response class, state-changing behavior, source artifact, and confidence.

Do not merge operations when method, body shape, parser, auth state, role, tenant, owner, response behavior, or workflow state differs. Preserve exact endpoint-to-field provenance; a global parameter list is insufficient.

## Prioritize attacker-relevant surface

Rank concrete operations higher when they expose:

- login, reset, MFA, invite, token, session, or account lifecycle behavior;
- admin, role, tenant, membership, ownership, billing, entitlement, approval, or settings functions;
- object IDs in any carrier, bulk/composite IDs, exports, downloads, or sensitive response fields;
- upload, import, preview, render, conversion, callback, webhook, URL-fetch, or integration behavior;
- price, total, quantity, discount, status, state, owner, tenant, role, or idempotency fields;
- HTML/Markdown/template input, search/filter/sort expressions, file paths, XML, or serialized data;
- undocumented versions, hidden client routes, debug endpoints, source-map leads, or role-specific discrepancies.

Priority controls review order only. Do not discard lower-ranked operations.

## Close coverage gaps

Read [coverage-gates.md](references/coverage-gates.md). Assign every discovered item one terminal state: `visited`, `runtime_confir

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-review-tahr-findings
description: Read applications, assessments, and findings from an already configured Tahr MCP connection. Trigger only when the user explicitly asks to query, list, summarize, or review Tahr account data; do not trigger for generic security reviews, source-code reviews, or non-Tahr findings.
---

# Review Tahr Findings

Use this optional, read-only workflow for existing Tahr customers who have manually configured the Tahr MCP server in Codex. This is a Codex/local manual integration only. Never claim that it provides public ChatGPT account linking.

## Establish account context

Start every explicit Tahr-data request with `get_context`. Before querying account data, confirm and report the authenticated organization name and the relevant capabilities. If the user named a different organization, stop and ask them to switch or reconfigure the connection; do not query the authenticated organization.

Respect the reported capabilities:

- Access applications only when `canReadApplications` is true.
- Access findings only when `canReadFindings` is true.
- Treat this workflow as read-only even when `canEditFindings` is true.

Use only these tools: `get_context`, `list_applications`, `get_application`, `list_assessments`, `list_findings`, and `get_finding`. Never invoke mutation tools or perform write, triage, status, or comment actions.

## Handle connection failures safely

If the MCP server or tools are unavailable, authentication returns 401, the token is missing, revoked, or expired, permission fails, or the service is unavailable or rate limited, give concise setup or recovery guidance. Suggest checking that the personal token environment variable and Codex MCP configuration are present, restarting Codex, obtaining the required organization access, or retrying later as applicable. Never ask the user to paste a token into chat. Offer to continue with the independent local security skills.

## Resolve and query records

Resolve a human application name with `list_applications`, then use the exact application ID returned by Tahr. Do not reveal details for null, missing, or cross-organization resources.

List tools accept optional `cursor` and `limit` parameters. Use a limit from 1 through 50; the default is 25. Responses contain `items` and `page.{nextCursor,isDone}`. Paginate only when the user requests all or complete results. For each subsequent page, keep every filter unchanged and pass the prior `nextCursor`. Otherwise, stop when the request is satisfied and disclose the coverage limit.

For `list_findings`:

- Always provide `kind` as `security` or `authorization`.
- Use the default `assessmentScope: latest` unless the user explicitly requests history or all assessments; only then use `assessmentScope: all`.
- Filter as needed by `applicationId`, `assessmentId`, or severity: `Critical`, `High`, `Medium`, `Low`, or `Info`.
- When generic "findings" clearly means both security and authorization findings, query each kind separately. Otherwise, clarify the ambiguity before querying.

Use `get_finding` only when requested or needed for the requested detail. Treat returned records as Tahr platform records, not independently verified vulnerabilities. Preserve finding IDs and assessment IDs in summaries where helpful, and distinguish recorded evidence from claims.

If list items are empty, report only that no matching records were returned; do not speculate. If a get operation returns null, report that the resource is unavailable without disclosing whether it exists elsewhere.

## Protect data and report results

Do not send repository content, secrets, credentials, tokens, or unrelated chat data to Tahr. Never log or persist the bearer token.

Provide concise result summaries grouped by severity or application as requested. State whether the summary covers all matching pages or only the pages and item limit queried.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: tahr-secure-app
description: Perform an evidence-backed, pentester-style security review of an application from source, configuration, specifications, tests, and optionally an explicitly authorized local or staging runtime. Use for comprehensive app security audits, pentest readiness, pre-release reviews, dangerous-flaw discovery, or coordinating the Tahr specialist skills; also use when a prior scanner or LLM review created confidence that needs independent verification.
---

# Tahr Secure App

Review the application as an attacker would: map what is reachable, form target-specific hypotheses, try to disprove each candidate, require exploit-class proof, and account for what was not tested.

## Set the review mode

Choose one mode and state it before reviewing:

- `deep`: inspect every admitted first-party file and close every high-risk gap. Use by default for “secure this app.”
- `focused`: review a named feature or boundary deeply and list excluded areas.
- `retest`: verify an accepted fix with `$tahr-verify-security-fix`.

Treat source and local artifact inspection as read-only review. Run runtime probes only against a local, disposable, or explicitly authorized test target. Do not infer permission to test production, third parties, other tenants, or real accounts. Use low-impact canaries, disposable objects, bounded concurrency, and reversible actions. Never persist raw passwords, tokens, cookies, private keys, personal data, or cloud credentials.

## Create the evidence ledger

Read [references/evidence-contract.md](references/evidence-contract.md) before classifying any issue. Use [assets/review-report.template.json](assets/review-report.template.json) when a durable JSON artifact is useful. Write artifacts only where the user requests or in a clearly named local review directory; do not modify application code during a review.

Keep three lanes separate throughout the work:

1. `findings`: claims that meet the applicable proof status.
2. `candidates`: concrete leads whose required proof is incomplete.
3. `coverage`: reviewed, partial, blocked, skipped, and not-applicable scope.

Never promote a scanner hit, dangerous function name, package advisory, route name, response status, reflection, timing change, accepted upload, or prior report statement by itself.

## Map before judging

Inventory the application before searching for bugs:

- first-party files, frameworks, manifests, lockfiles, infrastructure, deployment and CI configuration;
- HTTP routes, GraphQL resolvers, RPC/gRPC handlers, WebSockets/SSE, webhooks, uploads, callbacks, serverless functions, CLI entrypoints, queues, jobs, and externally influenced schedulers;
- actors, roles, service principals, tenants, organizations, groups, ownership fields, sessions, and recovery flows;
- assets, data stores, secrets, billing or entitlement state, admin/debug functions, AI models, RAG sources, tools, and external integrations;
- browser routes, lazy chunks, source maps, API clients, mobile deep links, and undocumented or legacy API versions.

Follow thin controllers into middleware, policies, services, repositories, serializers, templates, and asynchronous consumers. Mark each admitted item `reviewed`, `partial`, `blocked`, `skipped-with-reason`, or `not-applicable`. Low apparent risk is a reason to review briefly, not to disappear the file from coverage.

Use `$tahr-map-attack-surface` when the reachable surface or identity coverage is unclear.

## Build attacker hypotheses

Create target-specific hypotheses in four forms:

- `actor -> action -> resource -> owner/tenant boundary -> expected decision`;
- `untrusted source -> transformations -> dangerous sink -> expected control`;
- `workflow state -> attempted transition/replay/race -> invariant -> authoritative readback`;
- `deployment input/default -> privileged capability or sensitive asset -> compensating control`.

Prioritize unauthenticated paths, cross-user or cross-tenant boundaries, state-changing fun

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 5 — file references are metadata, not package contents.

View saved version →

---
name: tahr-test-access-control
description: Perform complete or focused, evidence-backed access-control review from source and optionally an explicitly authorized local or staging runtime. Model subjects, roles, tenants, resources, actions, properties, policy rules, enforcement points, and owner-attributed test cases; trace object-, function-, property-, role-, and tenant-level authorization through REST, GraphQL, web, job, and asynchronous paths; safely validate IDOR/BOLA/BFLA, mass assignment, privilege escalation, and cross-tenant isolation; and reject status-code or guessed-ID false positives. Use for authorization code review, multi-user or multi-tenant assessments, admin and role boundary analysis, pre-pentest review, or validation of a suspected access-control finding.
---

# Tahr Test Access Control

Determine exactly who can perform which action on which resource, property, or
function—and prove when the implementation violates that application-specific
rule. Produce an authorization model and proof ledger, not a status-code diff.

## Load the operating contract

Before reviewing:

1. Read [full-review-workflow.md](references/full-review-workflow.md) for scope,
   execution order, completion, and lifecycle rules.
2. Read [access-control-data-contract.md](references/access-control-data-contract.md)
   for stable IDs, exact enums, and record relationships.
3. Read [access-matrix.md](references/access-matrix.md) before constructing
   operation, relationship, carrier, property, or variant coverage.
4. Read [access-proof-gates.md](references/access-proof-gates.md) before
   accepting or rejecting a candidate.
5. Read [runtime-test-safety.md](references/runtime-test-safety.md) before any
   runtime action.
6. Read [source-review-patterns.md](references/source-review-patterns.md) when
   source is available.
7. Use [worked-example.md](references/worked-example.md) only when the expected
   evidence-to-finding trace is unclear.

Start from [access-control-review.template.json](assets/access-control-review.template.json)
and keep [access-control-review.schema.json](assets/access-control-review.schema.json)
as the canonical output contract. Maintain one `access-control-review.json`;
derive all reader-facing artifacts from it.

## Choose scope and assurance honestly

Set `review_mode` to:

- `full` for every admitted authorization-relevant operation in the existing
  application; or
- `focused` for explicitly named operations, findings, resources, or policy
  boundaries.

Default to `full` when the user asks to review or secure the application and
does not explicitly narrow the authorization scope.

Set `analysis_basis` to `source_only`, `runtime_only`, or `hybrid`. A focused
review must carry a visible limitation and must not make an application-wide
claim. A source-only review may be `complete` with `source_observed` assurance
and planned runtime tests when every declared source surface is dispositioned.
It must not claim that an attack ran or that deployed enforcement failed.

Keep these states separate:

- `review_status`: whether the declared authorization scope was dispositioned;
- `assurance_status`: source observation versus authorized runtime validation;
- candidate `disposition`: lead, follow-up, rejected, source-confirmed, or
  runtime-confirmed;
- test `execution_status`: planned, passed, failed, inconclusive, or blocked;
- coverage `status`: reviewed, tested, pending, deferred, or out of scope.

Default to read-only analysis. Never start an application, send a request,
refresh a session, or mutate state unless the exact target and action class are
authorized. Never commit, patch, or reconfigure the reviewed application as
part of this skill.

## Freeze the review inputs

For source or hybrid review, create a deterministic manifest in the selected
output directory:

```bash
python3 <skill-directory>/scripts/build_review_manifest.py \
  path/to/application --include . \
  --output path/to/output/repository-manife

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 13 — file references are metadata, not package contents.

View saved version →

---
name: tahr-test-ai-agents
description: Test security boundaries in applications that use LLM chat, RAG or vector retrieval, memory, file or URL ingestion, model-rendered output, tool/function calling, MCP, or autonomous agents. Use for source-backed AI feature reviews, authorized local or staging runtime tests, prompt-injection assessments, cross-tenant retrieval checks, agent/tool abuse reviews, and AI resource-control testing.
---

# Tahr Test AI Agents

Review the application as an attacker crossing data, instruction, identity, rendering, and tool boundaries. Treat payload catalogs as aids; make the proof discipline the center of the assessment.

## Establish the boundary

1. Confirm the repository, feature, identities, and runtime target placed in scope.
2. Default to source-only analysis when authorization for active runtime testing is unclear.
3. Identify protected accounts, production data, third-party integrations, and actions that must remain read-only.
4. Do not modify application code, configuration, or deployed state unless the user separately requests remediation.
5. Use disposable tenants, documents, objects, tools, callback collectors, and marker values for active tests.

Never delete data, transfer value, send real messages, publish content, rotate credentials, change privileges, exhaust a customer budget, or exfiltrate real private data. Bound concurrency, output length, request counts, and cost.

## Build the real attack surface

Read [methodology.md](references/methodology.md) before selecting tests.

Trace model and embedding SDK calls to their actual HTTP, WebSocket, queue, or background-job entry points. Include supporting routes for uploads, knowledge bases, conversations, memory, feedback, model settings, tools, and shared views. When source is incomplete, inspect OpenAPI, client bundles, forms, runtime requests, streaming frames, and error shapes.

Confirm an endpoint only when it accepts AI-shaped input or produces generated, streaming, retrieval, embedding, model, or tool behavior. A route name containing `chat`, a generic JSON response, or a successful status code is not confirmation.

For each confirmed surface, record:

- endpoint, method, controllable field, and authenticated identity;
- tenant, conversation, memory, and retrieval context;
- model/provider and guardrail hints, marked `unknown` when unproven;
- ingestion formats and retrieval sources;
- renderer and downstream output sinks;
- available tools, resources, prompts, and autonomous steps;
- measured rate, token, output, streaming, and quota behavior;
- evidence source and confidence.

## Test conditionally

Establish a benign baseline before attack probes. Run only families whose preconditions exist:

- test direct instruction override against an application-specific control;
- test indirect injection only through content the application really ingests;
- test retrieval and memory across validated user or tenant boundaries;
- test output injection in the actual browser or downstream consumer;
- test tool and MCP agency at real resource and authorization boundaries;
- test resource controls with conservative measured probes;
- attempt chains only from previously observed signals.

Vary semantic attack concepts before cosmetic encodings. Record every attempt by endpoint, field, concept, payload hash, response class, and success criterion. For stochastic behavior, reproduce the same concept and boundary at least three times in five attempts unless the original security contract requires a stronger threshold.

When blocked, ask at most a few fresh-agent passes for concise new concept axes or plausible chains. Treat that advice as leads only. Never let an adviser, model claim, or payload classification verify a finding.

## Apply proof gates

Read [proof-gates.md](references/proof-gates.md) before promoting or scoring a result.

Maintain three separate collections:

1. **Verified findings** — the required boundary and impact proof exist

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-test-authentication
description: Review and safely test web authentication and session boundaries across login, registration, password reset, magic links, MFA or OTP, OAuth/OIDC, SAML, passkeys, tokens, cookies, logout, and recovery. Use for authentication code review, pre-release auth testing, account-takeover analysis, session-management review, SSO integration review, or validating an existing security assessment.
---

# Test Authentication

Find identity-boundary failures, not merely unusual responses. Treat auth material as untrusted until it proves the intended identity and transport.

## Establish safe scope

1. Identify source roots, runtime origins, supported authentication methods, supplied identities, and expected account lifecycle.
2. Do not send runtime requests unless the user supplied or authorized the target. Use source-only analysis otherwise.
3. Treat all supplied accounts as protected unless explicitly labeled disposable. Do not lock, reset, disable, delete, re-role, enroll or remove MFA/passkeys, rotate credentials, or invalidate all sessions on protected accounts.
4. Use invalid identifiers for low-volume response-shape checks and disposable accounts for lockout, reset completion, password changes, MFA mutation, code replay, and takeover proof.
5. Stop runtime testing on lockout text, CAPTCHA, rate limiting, disabled-account state, unexpected notification delivery, or unclear side effects.

## Prove identity truth first

For each supplied identity:

- observe the rendered login flow before submitting credentials;
- classify password, split-step, OTP, MFA, magic-link, OAuth/OIDC/SAML, passkey, browser-bound, and custom stages;
- identify hidden state, nonce, CSRF, tenant, organization, provider, or login-method choices;
- validate success against an authenticated-only or identity-confirming endpoint;
- record the observed user, role, tenant, auth mode, and whether cookies/tokens are portable or browser-bound.

Do not equate a cookie, token, callback URL, HTTP 200, account picker, application shell, or pending MFA page with successful authentication. A failed role-specific login is a coverage blocker, not target access denial.

## Model the lifecycle

Trace these state transitions when present:

`registration/invite -> verification -> login -> step-up/MFA -> session refresh -> logout/revocation`

`forgot-password -> delivery -> token/code validation -> password change -> prior-session behavior`

`OAuth/SAML/passkey initiation -> provider/authenticator -> callback/completion -> application session`

Record every endpoint, browser action, actor, token class, binding, one-time expectation, expiry, and alternate/mobile/legacy channel. Derive endpoints from source, specifications, JavaScript, and observed traffic before using fallback names.

## Execute the abuse matrix

Read [auth-matrix.md](references/auth-matrix.md). Prioritize tests that cross an identity boundary:

- valid-disposable versus invalid account enumeration controls;
- rate limiting and weaker alternate endpoints;
- pre-auth, post-password, post-MFA, and fully authenticated stage skipping;
- token/code replay, wrong-account binding, stale-token reuse, and parallel requests;
- recovery, factor, password, email, and security-setting changes without reauthentication;
- session fixation, logout/timeout invalidation, CSRF, cookie scope, and refresh rotation;
- OAuth redirect/state/nonce/PKCE/code/client/scope binding;
- credentials or reusable secrets in URLs, responses, logs, JavaScript, caches, or browser storage.

Change one dimension at a time and pair every abuse attempt with a valid control. Refresh or re-establish the exact identity after an intentionally invalidating test before interpreting later responses.

## Apply proof gates

Read [auth-proof-gates.md](references/auth-proof-gates.md). Keep endpoint discovery, header observations, raw tokens, configuration smells, status codes, timing, and script labels in a candidate ledger 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-test-business-workflows
description: Model and safely abuse-test stateful business workflows, API operations, and application invariants such as checkout, billing, credits, invitations, approvals, entitlements, exports, uploads, integrations, quotas, and asynchronous jobs. Use for business-logic review, race-condition and replay testing, mass-assignment or excessive-property review, workflow bypass analysis, API version/parser comparison, or pre-pentest testing of critical product flows.
---

# Test Business Workflows

Look for normal-looking requests that produce outcomes the business never intended. Prove the outcome, not merely that an unusual value was accepted.

## Bound the work safely

1. Identify source roots, specifications, runtime scope, supplied identities, sandbox/test mode, and critical workflows.
2. Do not send live requests without clear authorization. Use source, tests, schemas, and captured traffic to model workflows otherwise.
3. Treat supplied accounts, customer data, billing objects, orders, balances, coupons, invitations, and integrations as protected.
4. Require a disposable fixture or explicit dry-run/preview/test mode before creating orders, changing plans or roles, transferring value, consuming benefits, sending messages, registering webhooks, or mutating persistent state.
5. Define before state, expected effect, authoritative readback, restoration, and cleanup before every mutation or race batch. Stop on unexpected side effects or instability.

## Reconstruct the real workflow

For each critical workflow, combine code, UI, schemas, tests, background jobs, JavaScript, and authorized traffic. Record:

- actors, roles, tenants, objects, and ownership;
- entry conditions and server-side prerequisites;
- states, transitions, terminal states, and asynchronous steps;
- authoritative values and where each value originates;
- one-time tokens, idempotency keys, approvals, expiries, counters, and quotas;
- compensating actions, cancellation, rollback, and cleanup;
- alternate API versions, clients, content types, bulk operations, and direct endpoints.

Write explicit invariants such as “the server calculates the total,” “only the current owner may approve,” “a code is redeemed once,” or “a transition requires the immediately preceding state.” Cite the evidence for each invariant; do not invent product rules from route names.

## Derive an abuse plan

Read [workflow-abuse-matrix.md](references/workflow-abuse-matrix.md). Cover applicable classes:

- boundary values, type confusion, omitted fields, extra fields, nested/array forms, and duplicate parameters;
- client-controlled price, total, discount, tax, quantity, balance, owner, tenant, role, status, approval, entitlement, or feature fields;
- direct access to later steps, skipped/reordered prerequisites, repeated actions, stale token/state reuse, and alternate actors;
- duplicate submission, idempotency collisions, last-byte/single-packet concurrency in a disposable environment, and time-of-check/time-of-use gaps;
- rate/quota limits on sensitive successful operations;
- version, method, parser/content-type, mobile/legacy, bulk, GraphQL alias/batch, and asynchronous variants;
- excessive response properties, unsafe third-party responses, webhook signature/event handling, and generated-link/cache-key trust.

Rank high-impact invariants first, but give every discovered workflow or operation a terminal disposition. Do not replace target-derived requests with guessed endpoints or generic bodies.

## Execute paired experiments

For authorized runtime work:

1. Capture a valid single-request baseline and define what proves business success.
2. Change one invariant-related dimension while holding actor, object, method, body, parser, and timing constant.
3. Use a negative control and, where useful, an authorized control.
4. Read the authoritative state after the attempt; also inspect related list, audit, balance, entitlement, or downstream job state.
5. 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-threat-model-app
description: Build a full, implementation-backed threat model of an entire existing application, covering actors, assets, trust boundaries, entrypoints, hop-level data flows, abuse cases, connected attack paths, security invariants, control gaps, risk responses, and executable validation handoffs. Use for comprehensive system threat modeling, security architecture assessment, pentest preparation, or correlating a complete application repository with configuration, IaC, API schemas, diagrams, and deployment documentation. Do not use for a feature-only, diff-only, or design-only review.
---

# Tahr Threat Model App

Model the entire existing application as an attacker would. Use source and
configuration for observed implementation, documents for intended behavior,
and runtime evidence only when the exact target and test are authorized.
Produce a decision and validation plan, not a code-smell list and not a
verified-vulnerability report.

## Load the operating contract

Before modeling:

1. Read [full-review-workflow.md](references/full-review-workflow.md) for the
   end-to-end sequence and completion gates.
2. Read [threat-model-ledgers.md](references/threat-model-ledgers.md) for the
   canonical record relationships and exact enums.
3. Read
   [threat-evidence-and-quality-gates.md](references/threat-evidence-and-quality-gates.md)
   before accepting threats, risk ratings, or a complete status.
4. Read [specialist-handoffs.md](references/specialist-handoffs.md) before
   assigning validation work to another Tahr skill.
5. Use [worked-example.md](references/worked-example.md) only when the expected
   evidence-to-test trace is unclear.

Use [threat-model.template.json](assets/threat-model.template.json) as the
starting structure and [threat-model.schema.json](assets/threat-model.schema.json)
as the output contract. Do not invent a different report structure.

## Establish full-application scope

Record the repository path and revision, packages, services, clients,
deployment environments, supplied specifications and documents, excluded
third-party internals, runtime authorization, previous model, and unanswered
questions. Keep `mode` equal to `full`.

Cover every admitted first-party application component. If time, access, or
missing evidence prevents full coverage, preserve the complete inventory,
disposition each gap, and set `model_status` to
`incomplete_high_risk_coverage`. Never silently narrow a full review.

Keep these concepts separate:

- `model_status`: whether the declared full scope has been dispositioned;
- `assurance_status`: whether conclusions are source-observed or also
  runtime-validated;
- `risk`: plausible impact and likelihood of a modeled threat;
- `confidence`: strength and completeness of supporting evidence;
- `execution_status`: whether a validation test is only planned or has an
  authorized result.

A source-observed model may be `complete` while validation tests remain
`planned`, provided runtime validation was not part of the declared scope and
all implementation evidence was dispositioned. Express the limitation through
`assurance_status`; do not misuse coverage status to imply a test ran.

Default to read-only analysis. Do not test production, third parties, real
tenants, or real accounts without explicit authorization. Redact credentials,
tokens, keys, personal data, and customer data from every artifact.

## Inventory before judging

Build a coverage baseline from all first-party files and supplied evidence.
Inspect source, manifests and lockfiles, configuration, CI/CD, IaC, containers,
API and GraphQL schemas, database models, tests, diagrams, role matrices,
workflows, integration notes, and deployment documents. Map:

- human, service, worker, administrator, support, peer, tenant, and third-party
  actors;
- critical business, identity, authorization, financial, operational, privacy,
  audit, and secret assets;
- clients, APIs, services, workers, queues, data st

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 11 — file references are metadata, not package contents.

View saved version →

---
name: tahr-trace-dangerous-inputs
description: Trace attacker-controlled input through parsing, validation, normalization, storage, and dangerous server or browser sinks, then safely validate exploitability with class-specific proof gates. Use for injection review, source-to-sink analysis, XSS, SQL/NoSQL injection, command or template injection, SSRF, XXE, path traversal, unsafe deserialization, file upload/processing, webhook, CORS/postMessage, or client-side trust-boundary testing.
---

# Trace Dangerous Inputs

Find complete attacker-controlled data paths. Do not report a dangerous API call, suspicious regex match, reflection, or error without proving reachability and impact.

## Set a safe review mode

1. Identify repository roots, runtime targets, specifications, traffic, authentication context, and authorized scope.
2. Default to static tracing when live testing is not explicitly authorized.
3. Keep runtime probes low volume, non-destructive, and tied to exact discovered operations. Do not test login credential fields, customer objects, real payment/order flows, or unrelated infrastructure.
4. Require a disposable fixture before uploads, persistent content, webhook registration, or other mutations. Define readback and cleanup first.
5. Use harmless unique markers, controlled callbacks, safe owned canaries, and low-impact commands only. Never delete data, establish persistence, dump broad files/databases, scan internal networks, or alter cloud resources.

## Build the source-to-sink map

Read [source-sink-matrix.md](references/source-sink-matrix.md). For every candidate path, record:

- entrypoint and exact source: path, query, body, nested field, header, cookie, form, multipart metadata, GraphQL variable, message, file, stored value, or browser source;
- parsing and canonicalization order, including decoding, type coercion, content-type selection, duplicate parameters, archive/document parsing, and redirects;
- validation, allowlisting, authorization, normalization, encoding, parameterization, and sanitization controls;
- transformations and trust-boundary hops across services, queues, jobs, databases, caches, templates, browsers, and third parties;
- final sink, execution context, and output/render/fetch/readback path.

Trace second-order behavior: input stored now may later reach a query, template, browser render, document processor, shell, webhook, or background job.

## Prioritize real sinks

Prioritize operations evidenced by code, schemas, JavaScript, or traffic:

- query builders and raw SQL/NoSQL/search expressions;
- shell/process APIs, dynamic evaluation, deserializers, and template engines;
- URL fetchers, redirects, webhooks, integrations, image/document renderers, and import/export jobs;
- XML parsers, file/path/archive operations, upload pipelines, and served-content behavior;
- HTML/DOM/navigation/eval-like browser sinks, postMessage handlers, and cross-origin data access.

Do not send a payload to the application root merely because a field name looks interesting. Preserve the actual method, body, parser, auth/role/tenant context, and provenance.

## Validate progressively

For an authorized runtime target:

1. Establish a clean baseline and the operation's real success semantics.
2. Send a unique inert marker to prove the source reaches the expected context.
3. Change one field, encoding, parser, or carrier at a time using a context-specific safe probe.
4. Distinguish filter/WAF behavior from application execution.
5. Follow the result to the final proof surface: database-derived value, command output, callback, safe file canary, browser runtime effect, persisted readback, internal-service response, or served upload behavior.
6. Repeat with a negative control and preserve exact request/action and response/proof artifacts.

If runtime proof is unavailable, report the full reachable code path and missing precondition as a candidate or code-level risk. Do not claim confirmed exploitability.

## Apply cl

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: tahr-verify-security-fix
description: Retest a security fix in the exact vulnerable context, decide whether the exploit path is closed, and validate secure remediation and regression coverage without breaking legitimate behavior. Use after a vulnerability patch, remediation commit, PR fix, dependency or configuration change, failed security retest, or when developers need proof that a fix is complete rather than a superficial code change.
---

# Tahr Verify Security Fix

Verify the failed security control and the attacker outcome, not merely the
presence of a patch. Preserve the original finding, proof, context, and scope so
a different identity, tenant, route, payload, deployment, or render path cannot
produce a false pass.

## Establish retest authority and safety

1. Record the original finding ID, exact claim, required proof, original
   positive evidence, affected revision, fix revision, and supplied patch.
2. Record the original actor/role, owner/tenant/object, endpoint or workflow,
   method/content type, payload class, state, configuration, render/trigger
   context, and final impact.
3. Default to source and test inspection. Exercise only an explicitly
   authorized local or staging target. Do not infer permission for production,
   third-party, destructive, credential-changing, billing, or broad data tests.
4. Use disposable accounts and fixtures. Preserve protected identities and
   extract only the minimum proof sample.
5. Redact passwords, cookies, bearer/session tokens, API keys, private keys,
   reset codes, personal data, and customer data. Retain only type, location,
   and hash/fingerprint when necessary.

Read [exact-context-retest-verdicts.md](references/exact-context-retest-verdicts.md)
and create separate candidate, proof, and coverage records before testing.

## Inspect the remediation

Trace the original source-to-sink or missing-control path through current code.
Identify:

- the exact failed control and where the patch now enforces it;
- existing project policy, ownership/tenant scope, validator, sanitizer,
  encoder, parameter binding, allowlist, network guard, or safe API reused;
- adjacent route, resolver, service, repository, serializer, worker, webhook,
  content type, method, redirect, or render path that may bypass the fix;
- public behavior, auth semantics, tenant rules, response shape, data
  invariants, and framework lifecycle that must remain compatible.

Search for a concrete contradiction to the fix claim. A new helper, regex, test,
or guard name is not proof that the effective path uses it.

## Retest in the exact context

1. Reproduce the original benign baseline.
2. Replay the original exploit or closest safe equivalent using the original
   actor, ownership/tenant relation, route, content type, state, and trigger.
3. Confirm the expected denial, encoding, validation, scoped result, blocked
   network/file action, safe query, or non-execution result.
4. Read back durable state or observe the final sink. Do not stop at the first
   accepting or rejecting layer.
5. Run a positive control proving the legitimate owner, tenant, role, input, or
   workflow still succeeds.
6. Run class-relevant alternate encodings, methods, content types, object IDs,
   roles, tenant relationships, render contexts, redirects, or concurrency
   variants within the safe budget.
7. Test sibling paths that share the changed control.

Use fresh, identity-matched sessions and prove object/tenant ownership for
authorization retests. A `200`, body-size change, reflection, upload acceptance,
tool success flag, timeout, stale session, or WAF response is not a retest
verdict by itself.

## Assign an exact verdict

Assign one verdict from the reference contract:

- `FIX_VERIFIED`;
- `FIX_PARTIAL`;
- `NOT_FIXED`;
- `REGRESSION_INTRODUCED`;
- `INCONCLUSIVE`.

Support it with finding-local positive evidence, negative evidence, controls
tested, contradiction result, exact-context match, variants, limitations, and
f

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.