Operate Griffin safely

Customer safeguards

• Assess only assets your organization owns or is explicitly authorized to test.
• Keep target scope, authorization, and ownership evidence current.
• Use redacted evidence and never place credentials in targets, notes, or support requests.
• Treat unavailable or untested checks separately from successful results.

Prepare a bounded passive API inventory

Availability: early development. Passive API posture is a non-default profile that remains visible as Unavailable until the Griffin owner enables it. It is limited to public API targets marked development or test and remains unavailable for production targets.

The profile sends one sequential GET request to each selected inventory path. It does not crawl, discover additional paths, follow redirects, submit mutations, use credentials, or expand beyond the exact authorized public origin and path scope.

• Select between one and ten unique canonical relative paths. Paths must begin with / and must not contain a query, fragment, template, wildcard, full URL, header, body, credential, or mutation.
• Documented operation count records the size of the source inventory; it must be at least the number of selected paths and does not authorize Griffin to visit unselected operations.
• The inventory is bound to the current tenant, target scope, written authorization, and technical ownership proof. A scope or approval change makes the prior inventory unusable.
• Requests are GET-only, sequential, at least 100 milliseconds apart, limited to ten total, capped at 256 KiB each and 1 MiB total, limited to 5 seconds connection time and 30 seconds total runtime, and never follow a redirect.

1. Confirm the target is a public API marked development or test, then complete passive API authorization and technical ownership verification.
2. Open Scans, select + Add to open New scan, choose the exact target and Passive API posture, and review the current inventory state.
3. Enter the documented operation count and one to ten exact query-free GET paths, confirm the inventory attestation, and save the inventory.
4. Review preflight. If the target scope or authorization changed, create a new current inventory rather than trying to reuse the stale one.

Run and read a passive API assessment

A passive API scan requires a fresh one-scan confirmation after you select the current inventory. Consent expires quickly, can be consumed only once, and cannot be reused by a schedule or automatic retest.

Griffin presents only canonical query-free scope, fixed signal and classification names, confidence, severity, bounded counts, evaluation completeness, fixed limitations, and remediation guidance. Response bodies and detected values never appear in the result.

• Potential exposure categories include authentication material, credentials or secrets, private-key material, sensitive authentication properties, debug or database details, environment or configuration data, regulated-data bundles, and internal authorization metadata.
• Matched values, response bodies, excerpts, decoded claims, credentials, tokens, cookies, header or query values, and value or body hashes are never retained or displayed.
• Incomplete, unavailable, failed, cancelled, or historical results that lack aggregate detail cannot clear an earlier finding or establish absence.
• A potential-exposure result does not confirm an authorization weakness, credential validity, exploitability, complete OWASP API Security Top 10 coverage, certification, or compliance.

1. Select the current inventory and confirm I consent to this bounded passive API assessment for this scan only.
2. Start the manual scan, then open its details to review endpoint outcomes, fixed signals, and the ten-category limitation matrix.
3. Open a related finding to review its aggregate classification and fixed remediation guidance without copying suspected content into Griffin or a support request.
4. Run a new authorized scan with fresh consent when you need a retest. Do not use an incomplete or unavailable result as evidence that a finding is resolved.

Run sensitive-response inspection safely

Availability: early development. Sensitive response exposure (development) is a non-default profile that remains visible as Unavailable until the Griffin owner enables it. It is limited to targets marked development or test and remains unavailable for production targets.

The profile makes one bounded request and passively inspects its already-retrieved body only when the response is not a redirect. It sends no additional requests and does not validate, replay, decode, or attempt to use anything it may classify.

• Potential exposure categories cover authentication material; credentials or secrets; private-key material; sensitive authentication properties; debug or exception details; database error details; environment or configuration data; regulated-data bundles; and internal authorization metadata.
• Response bodies, matched values, tokens, API keys, credentials, excerpts, decoded claims, and value or body hashes are not retained or displayed.
• Results contain only a potential-exposure category, bounded occurrence count, confidence, evaluation completeness, declared media type, remediation guidance, and the public origin and path.
• A result indicates a potential exposure. It does not prove that a credential is valid, that data is exploitable, or that an authorization control can be bypassed.
• Unsupported content types or encodings and incomplete responses are reported as not tested or incomplete. An unevaluated category is not evidence that the exposure was cleared.
• A redirect is terminal. Griffin does not read its body or follow, display, log, or save its Location value; it reports all nine categories as not evaluated at the original approved endpoint.
• Scheduled scans and automatic finding retests cannot use this profile. Start a new manual scan and consent again when a retest is needed.

1. Confirm that the target is marked development or test and has active authorization that includes sensitive-response inspection.
2. Open Scans, select + Add to open New scan, choose the exact target, and select Sensitive response exposure (development).
3. Select I consent to sensitive-response inspection for this scan only immediately before starting the scan.
4. Start the manual scan, then open its details or related finding to review the aggregate classification and remediation guidance.
5. If Griffin reports a potential exposure, validate it through your authorized application workflow without copying a response body or suspected secret into Griffin or a support request.

Review cycle

1. Confirm the workspace, scope, and product access before a sensitive action.
2. Review the product result with the accountable customer owner.
3. Record the decision and assign follow-up work.
4. Verify the outcome before closing the task.
5. Revisit policies, access, and notification paths when the environment changes.

Get support

When contacting support about Griffin, include the workspace, affected workflow, approximate time, and any visible correlation identifier.