# What Kit Security does. Receive vulnerability reports, keep researchers informed and track the team’s response. [Security & VDP features | Kit](https://startupkit.app/security/features) ## Receive and assess reports A researcher submits a finding. Your team has the evidence, owner and next decision. ### Send the finding without an account. Vulnerability reports Researchers describe the affected endpoint, explain the issue and attach evidence. An email address is optional. - Collect a title, vulnerability type, endpoint and description. - Add reproduction steps, a claimed severity and supporting files. - Record policy acceptance and provide a receipt after submission. Up to 10 files, each under 25 MB and under 50 MB combined. Email-free reports still carry submission metadata; email updates and portal identity require an address. ### Give researchers a place to start. Branded security portal Put your program description, reporting form and policy on a security portal with your branding. - Choose your logo, colors, tagline and brand visibility. - Use Kit hosting or a verified custom security domain. - Work through setup, preview drafts and activate or pause intake. One Security program per account. Public visitors need an active program; custom domains require Security subscription access. ### Write down what researchers may test. Scope and disclosure policy Publish accepted targets, exclusions and disclosure rules beside the report form. - List in-scope targets, excluded areas and vulnerability types. - Copy configured scope as Markdown. - Publish your disclosure policy, optional safe-harbor text and participation guidance. Safe harbor is your policy commitment. Scope checks use configured target strings and vulnerability types; Kit does not discover your attack surface. ### Leave with a reference and a receipt. Report receipts Researchers can return to the submitted write-up and current status through their receipt link. - Copy the report reference and see the submission time. - Read the description and reproduction steps again. - See attachment names without exposing download links. Receipt links grant bearer access for 90 days. The receipt excludes internal notes and is separate from the authenticated conversation. ### Follow the report through an email link. Private researcher portal Researchers sign in by email to see their own reports, assessment and reward progress across participating programs. - Open a magic link and confirm the researcher identity. - Read the evidence, status, team severity and assessed CVSS score. - Start a new report for an active public program. An existing researcher record is required. Sign-in links expire after seven days and newer links supersede older ones. Internal notes, staff CVSS vectors and private team tools stay hidden. ### Keep the reply with the finding. Researcher conversation Exchange report messages with the researcher. Sent team replies arrive by email and appear in the private portal. - Follow live messages in send order. - Request clarification in the same conversation. - Track unread messages separately for each teammate. Internal notes and unsent drafts stay private. Researcher portal messaging closes on dismissed or paid reports. ### Open the reports that need attention. Response queue Review open reports, waiting replies and unassigned work in a list or lifecycle board. - Switch between all, mine and team views; find Security attention in enabled Home and daily digests. - Search IDs or titles; filter status, severity, owner and screening results. - Order by SLA or submission date; assign or dismiss selected reports together. Counts follow report access; title search checks the newest 500 visible reports. Home digests honor preferences and skip unchanged or empty routine queues. Open permitted reports and actions from OmniSearch. ### Keep the claim beside the assessment. Severity and CVSS Build a CVSS base vector and record the team’s severity, assessor and reasoning. - Use the CVSS v3.1 base calculator. - Compare the researcher’s claimed severity with the team decision. - See the configured bounty-range suggestion. The current calculator uses CVSS v3.1 base metrics. Staff makes the assessment. ### Put a name beside the next action. Report ownership Assign a responder and keep the history when ownership changes. - Choose one active owner for the report. - Use a configured default or on-call assignment. - Retain recorded handoffs between responders. Assignment alone does not grant access to a restricted report. ### Keep the deadline beside the report. Response targets and clocks Publish your acknowledgment and severity-based resolution targets, then show the response window in the team’s queue. - Show configured targets on the policy page and llms.txt. - Read a live countdown with on-track, at-risk and breached states. - Prioritize the queue by the response deadline. The live window runs from submission time across open states. Resolution targets support idle thresholds and retrospective reporting; these are configured commitments, not staffed response guarantees. ### Record the outcome and its reason. Triage decisions Dismiss a report with a named reason, record an informative outcome or reopen it through a recorded transition. - Choose duplicate, scope or reproduction reasons. - Keep private rationale with the decision. - Retain the transition on the report timeline. Staff controls the decision. Informative is a separate outcome. ## Keep the response moving Keep replies, team notes, routing and on-call work beside the report. ### Read notes beside the report history. Team notes and history Discuss the finding privately and follow the people, decisions and handoffs recorded on the report. - Write general, assessment or decision notes, mention teammates and pin one note. - See staff viewers and their most recent report opens. - Follow status, severity, ownership, messages, postmortems, shares and integration events. Notes stay inside the authorized team. Viewer tracking can be disabled. A recorded action or view does not prove remediation or attention. ### Read the reply before it leaves. Reviewable reply drafts Keep an unsent report reply for your team to edit. Ask for a suggested response or polish the text in the composer. - Share one open draft with editor and send provenance. - See a warning when the researcher has replied since drafting. - Use thread context for suggestions, with a template fallback when unavailable. Drafts do not count as sent replies. Agent-written conversation replies default to unsent drafts; a program admin can enable direct sending. Authorized status or award changes can still send their normal notifications. An agent cannot silently replace human work. ### Preview the reply template. Message templates Customize reply wording and preview report and researcher variables before putting a message in the composer. - Prefill acknowledgments, clarification, validation, dismissal and bounty offers. - Set account defaults and program overrides. - Preview the resolved text before saving or sending a reply. Eleven template types can be managed, but five intents feed the reply composer. Automatic acknowledgment, status-change and sign-in emails use fixed mailer templates. ### Send researcher mail in your program’s name. Program email identity Match researcher notifications to the portal and use your security address when the email connection is ready. - Apply the program name, account logo and brand colors. - Provision a security@ identity through a ready email integration. - Send from your address with active Startupkit Email send-as. Your sender address requires active Startupkit Email send-as and DKIM. Otherwise mail uses a Kit address. Incoming email does not create Security reports or update conversations. ### Compare the finding before calling it a duplicate. Related reports See related reports from the same program beside the current finding. - Open near-duplicate and related suggestions. - Use same-type matches when embeddings are unavailable. - Follow direct links to reports you can access. Similarity suggests a comparison; staff makes the duplicate decision. Restricted reports stay hidden from unauthorized members. ### Read the reasons behind the flag. Report-quality screening Review a report-quality recommendation, confidence and specific signals alongside the submitted evidence. - See pass, review or flag recommendations. - Inspect the stated quality concerns. - Filter the inbox by screening result. Screening requires a configured provider and credits. Recommendations do not dismiss reports. ### Spot instructions aimed at the assistant. Prompt-injection warnings Show suspected prompt-injection techniques and their locations in researcher-written reports and messages. - Read the verdict, technique and affected field or message. - Distinguish vulnerability reports from follow-up, contact, support or test submissions. - Carry the warning into authorized MCP and assistant reads. Checks may be unavailable. A warning neither blocks the report nor prevents an authorized action, and a clean result is no guarantee. ### Open the history behind the report. Researcher history Review a researcher’s visible submissions, awards and karma events before deciding what the current finding needs. - Search researcher identities and filter their report history. - Inspect severity, award and karma records beside report links. - See a program-level low-signal marker and its counts after at least five reports. - Record admin karma adjustments through the assistant, with a preset reason, actor and optional evidence. The marker uses a reputation-count rule that includes pending reports. It does not dismiss, ban or lower severity. Global karma does not establish program-specific trust. ### Route the finding to its product area. Component routing Keep component patterns, owners and Slack destinations in a catalog, then confirm the suggested area on a report. - Match endpoint patterns and show why an area was suggested. - Use the component owner when the report has no owner. - Archive components while preserving report history. Suggestions need human confirmation. The catalog routes known areas; it does not discover assets or replace an existing responder. ### Nudge the report that has gone quiet. Owner reminders Use severity-based idle windows to remind the responder and escalate stalled work to an admin. - Follow team activity with a configurable reminder ladder. - Snooze for three or seven days within the episode allowance. - Mark when clarification is waiting on the researcher. Reminders exclude active snoozes, informational findings and qualifying researcher waits. Snoozing defers the episode without resetting the report clock. ### Set a time to return to the report. Report follow-up reminders Attach a timed reminder for yourself and teammates who can open the report. - Choose a local time and named teammates. - Receive an in-app notice, with email explicitly optional. - Complete, reopen or download an ICS calendar reminder. Researchers are never recipients. Delivery rechecks report access. Creators edit the reminder; participants can complete or reopen it. Calendar export is a snapshot rather than live synchronization. ### Give the next responder a handoff. On-call rotation Set the current responder and rotation, then send the incoming queue brief and outgoing shift summary. - Use manual shifts or daily and weekly rotations. - Account for holidays and notify admins about coverage gaps. - Include open work, approaching deadlines and shift activity in Slack or email briefs. Native rotation needs at least two members. PagerDuty schedule synchronization needs its configured connection. ### Send the alert to the responder. Response alerts and PagerDuty Notify on-call staff about urgent reports and response breaches, with optional PagerDuty escalation. - Choose new-report, SLA, critical-assessment and escalation triggers. - Map incident severity, configure breach repeats and sync the current on-call member. - Show PagerDuty acknowledgment and resolution updates from signed webhooks. PagerDuty requires your service connection and a matching Kit teammate. Reduced-content alerts protect restricted reports; incident resolution does not verify a fix. ## Follow the fix Hand work to engineering and record the evidence and decisions your team brings back. ### Keep the engineering issue beside the finding. Jira and Linear handoff Review a report’s disclosure before creating its Jira or Linear issue, then see the linked issue’s cached status in Kit. - Choose a project or team and map severity to priority. - Send selected milestone comments and approved vulnerability details. - See cached status, last synchronization, failures and broken links. Connections require provider setup. Vulnerability details need program permission and per-push consent. Tracker Done neither resolves the report nor proves deployment; unlinking leaves the external issue intact. ### Keep the pull request within reach. Remediation links Attach the issue, pull request or document your team uses to follow the fix. - Link GitHub, GitLab, Jira or Linear work. - Add custom labels and internal URLs. - Open linked references from the report timeline. These are staff-only references. Kit does not fetch their contents, sync their status or infer deployment. ### Record who marked the fix verified. Fix-verification decision An authorized teammate can move a resolved report to Fix verified and retain the decision on its history. - Keep Resolved and Fix verified as separate states. - Record the staff decision-maker and time. - Add an optional verification note. Kit does not require or independently verify deployment evidence or a researcher retest for this transition. ### Write the postmortem beside the finding. Postmortems Write corrective actions and lessons learned beside the report, with dates, attachments and retained revisions. - Record the root cause and corrective actions. - Enter detection and resolution dates. - Retain an append-only revision history. Time to fix uses the dates your team enters, rather than an observed deployment duration. ### Bring back evidence from your GitLab pipeline. Customer-run code triage Send one report to your own pipeline and return code locations, reproduction claims and remediation suggestions for review. - Use your repository, model and prompts with a scoped run token. - Track repository, commit, pipeline progress, failure and timeout. - Review proof-of-concept text, HTTP exchanges, tool output and coverage separately from the verdict. GitLab only; requires configuration and Security access. Runs time out after a configured 1–45 minutes. Up to eight evidence items, 64 KiB each and 256 KiB combined. Returned claims never change assessment automatically. ## Run your disclosure program Set access, recognition and reporting options around the researcher’s experience. ### Tell the researcher when the queue is behind. Queue notices and update requests Publish a queue notice and let eligible researchers request an update on a quiet report. - Show a custom notice and revised response-time text on intake, receipts and report pages. - Optionally send one notice for qualifying untouched reports after activation. - Let researchers add a short update request and see its next available date. Queue notices are off by default. Update requests apply to open reports after an overdue initial target or 14 quiet days, with a seven-day cooldown; they do not change severity. ### Give the decision a review path. Researcher appeals Researchers can submit a written appeal and follow the team’s response from their report page. - Keep the justification with the report. - Show pending, accepted or rejected results. - Apply the configured appeal cap and allow one pending appeal at a time. Eligible states include dismissed, informative, validated, resolved and fix verified. Paid reports are excluded. Accepting a closed-report appeal can reopen it; Kit provides no independent arbitration. ### Ask before publishing the researcher’s name. Recognition preferences Let researchers manage their handle, language and recognition choice, or answer an emailed credit request. - Offer named credit, anonymous credit and no listing equally. - Let the researcher edit the public name and retain the consent answer. - Show which programs list them and honor the global opt-out for linked entries. Request links expire after 30 days and unanswered resends have a seven-day cooldown. A named answer changes the global handle. Consent alone does not publish a credit; profile email is read-only. ### Give the contribution a lasting credit. Hall of Fame Curate researcher credits by year, with a stable page for each entry. - Feature selected entries with report counts and credit notes. - Add an optional external link to a credit page. - Record manual credits for work completed before Kit. - Review suggested credits and requests awaiting consent. Linked researchers need an explicit named or anonymous choice. Opt-outs hide linked entries and permalinks. Manual entries are staff-owned copy; the Hall of Fame can be disabled. ### Open the form through an invitation link. Invitation-only intake Choose public intake or require a program invitation, with an access-request form for researchers who want to join. - Restrict report and takedown forms with the shared invitation. - Review a researcher’s short access request. - Email approved invitations and rotate the program token. The link gates intake rather than the public policy or every discovery endpoint. It is not individual membership. Token rotation does not revoke already-granted browser sessions. ### Make the reporting route discoverable. security.txt and machine-readable policy Publish security contact details and a Markdown version of your policy, scope, rewards and submission guidance. - Preview security.txt and send expiration warnings through Slack. - Link llms.txt with required fields, attachment limits and report guidance. - Serve a portal sitemap and robots.txt for active public programs. Contact-file changes need a manual save. Expiration warnings use the saved timestamp. llms.txt describes personal web-form submission; sitemap and robots.txt require an active public program. ### Put the report form on your own site. Embedded reporting Embed the reporting form and keep its submission receipt inside the same context. - Copy the SDK snippet or direct iframe URL. - Use automatic iframe height updates. - Choose a light or dark theme and configure allowed framing origins. This is an embedded web form. Empty allowed origins are permissive; embedding does not provide a public report-submission API. ### Review the block as well as the report. Intake abuse controls Combine bot checks and rate limits with program block records that authorized staff can inspect and release. - Use a honeypot, configured Turnstile and burst thresholds. - Inspect blocked email or IP records, timing and refused attempts. - Flag likely false positives involving proven researchers and record manual blocks or releases. Controls reduce abuse without guaranteeing clean intake. Fixed web throttles and program limits both apply. Retryable failures retain typed text but require files again; shared-IP attribution is best-effort. ## Rewards and payouts Set an award, gather required details and keep the finance handoff on record. ### Publish the terms behind an award. Reward policy and ranges Describe recognition-only, discretionary or tiered rewards, with severity ranges in your program currency. - Set minimum and maximum amounts across six severity tiers. - Optionally publish the matrix and explain assessment. - Enable discretionary bonuses with a separate cap. - Approve a bounty or eligible bonus directly, without a team proposal. Matrix-based bounty limits depend on the assessment. All-zero tiers with bonuses off support recognition-only programs; empty tiers support discretionary rewards. These limits do not create a budget or escrow. ### Keep the amount and the team’s votes together. Bounty proposals Propose an award internally, collect agreement or counteroffers and leave approval with an authorized admin. - Use blind voting or optional live tallies with comments and counteramounts. - Keep earlier votes marked stale when the amount changes. - Ask an assistant for accessible prior awards, summary figures and recent examples. Proposals stay private until an award is approved. Approval does not transfer money. Prior-award queries include all award kinds and have no currency filter; they are internal history, not market benchmarks. ### Leave a record when the amount changes. Award corrections Adjust an approved award or withdraw an unpaid one with a reason and matching ledger entry. - Record the signed difference from the previous amount. - Optionally explain the change to the researcher. - Replace a withdrawn award without changing the report verdict. Completed or in-flight disbursements block corrections and withdrawal. A notified reduction requires a note. ### Invite one researcher back with a boost. Private bounty boosts Offer a researcher a private, time-limited multiplier for qualifying future reports in your program. - Progress through 1.1×, 1.25× and 1.5× milestones. - Cap the extra amount per report. - Add a personal notification or start the boost silently. Boosts last 7–90 days. Medium-or-higher validated qualifying findings drive progression. Terms freeze at submission, while eligibility depends on assessed severity; bonuses do not earn progression. ### Show what the payout still needs. Payout requirements Configure the documents, payment details and verification required before an award is ready for disbursement. - Choose agreement, verified tax document and fix-verification requirements. - Choose allowed methods and an optional recommendation; researchers add or update PayPal or bank details. - Set the program currency and minimum payout. Defaults require an accepted agreement, a verified tax document and a verified fix. Your team sends funds through its payment provider; Kit records the workflow. ### Keep the terms the researcher accepted. Accepted agreement records Use a default or custom bounty agreement and preserve the exact text when the researcher accepts it. - Use the built-in NDA or your program’s agreement text. - Collect explicit acceptance from the researcher’s report. - Retain the accepted text, timestamp and IP after later edits. Only the NDA agreement type is implemented. This is an optional prerequisite for an approved, payable bounty; it is not a pre-entry NDA gate, identity check or digital-signature service. ### Separate ready awards from blocked ones. Payout queue See which payouts need researcher details, team action or finance, and catch ready awards left waiting. - Filter ready, blocked, with-finance, paid and failed records. - Group shared blockers by researcher and see waiting amounts and the oldest award. - Remind the team while an award remains ready; reset the episode when blockers change. Queue totals are recorded amounts, not held funds. Reminders do not transfer money and stop when an award is no longer actionable. ### Ask for the details still missing. Missing payout details Send a focused researcher email covering outstanding payment information, tax documents and report agreements. - Group current researcher-owned blockers across their awards. - Link directly to the required portal actions. - See the last nudge time and apply the resend cooldown. Staff sends the nudge. It excludes staff-owned approvals or verification, under-minimum awards and unresolved award ceilings. This is separate from automatic team reminders for ready payouts. ### Give finance the payout record. Finance handoff Send a payout handoff and retain finance’s completion or failure confirmation. - Configure a finance email address. - Share payout details through a signed page; finance needs no Kit account. - Record the transaction reference and confirmer details. Finance schedules the transfer outside Kit. Confirmation is a human record rather than bank reconciliation. Without a finance address, staff records the outcome manually. ### Retry without erasing the failed attempt. Failed payout recovery Record the failure, request corrected details when needed and preserve the payout’s earlier attempts. - Distinguish invalid details, returned payments and unsupported methods. - Ask the researcher for replacement details. - Supersede an old attempt while keeping its history. An Other failure stays staff-facing until details are explicitly requested. Unsupported methods can require the program to offer another payment route. ### See the payout that needs another look. Payout review alerts Notify the approver when another person records completion, and alert other Security admins when the amount or approval history needs review. - Read approval, adjustment and completion details in the notice. - Flag differences between the award and its ledger-approved total. - Prompt independent review of material increases or unreadable approval history handled by one person. Routine self-completion stays quiet; review alerts exclude the person who completed it. These notices follow recorded completion and do not block or move money. Email delivery follows the applicable notification and holiday preferences. ### Keep the form and reviewer together. Tax document review Researchers upload a W-9 or W-8BEN for authorized staff or finance to review. - Use a raster preview for PDF review. - Record rejection reasons and the reviewer. - See document opens, download originals and send scheduled renewal notices. Access requires an awarded-bounty relationship and staff or finance authorization. Renewal notices use a three-year application threshold, not a legal expiry determination. Review does not file taxes or provide tax advice. ### Follow the award through every correction. Award and payout ledger Keep approvals, adjustments, revocations, payout attempts and tax decisions in the financial history. - Record each event’s actor and time. - Distinguish an adjustment delta from the resulting award. - Keep completed payouts separate from approvals. Ledger entries record payment confirmations. Kit does not transfer funds or reconcile bank accounts. ## Access and evidence Limit sensitive records, inspect response metrics and export the evidence. ### Choose who can open a sensitive report. Restricted reports Limit a report to named grantees and Security admins, with lead access for managing its routing and permissions. - Grant access to an individual report. - Let lead grantees manage access and routing. - Apply the report boundary to lists, metrics and MCP reads. Security admins retain access; assignment alone grants none. External shares and integration disclosures have separate boundaries. ### Give a peer an expiring report page. External peer sharing Share the technical finding with an outside engineer through an email invitation or view-only link. - Verify the invited mailbox and optionally collect staff-only peer comments. - Share technical content and researcher attachments through authorized downloads. - Revoke access and retain viewing, expiry and custody history. Access expires after seven days. Anyone links are view-only bearer credentials. Researcher identity, awards and internal notes stay hidden, but technical text and filenames are shared. Closing revokes existing shares. ### Give each teammate the right Security role. Security team roles Set Security access independently from other Kit work and assign finance capability separately. - Use security lead and security engineer presets. - Choose module member, admin or no access. - Separate payout and tax work through finance capability. Account admins retain overarching access. Hiring guest access is not a Security role. ### Encrypt the fields inside the record. Sensitive data encryption Store sensitive report text, researcher identity and payout details with application-level encryption. - Encrypt title, endpoint, description and reproduction steps. - Encrypt researcher email, name and payment details. - Authorize tax documents and attachments through their own access checks. This is Rails encryption at rest, not end-to-end encryption. No configurable per-report deletion schedule is provided. ### Read the response record over time. Security metrics Compare response and resolution time, SLA compliance, report volumes and recorded bounty payments. - Choose seven-, 30- or 90-day views. - Break reports down by severity, state and vulnerability type. - Keep unauthorized restricted reports out of aggregates. Paid totals use completed-disbursement records, with currencies separate. Metrics do not establish deployed fixes. ### Take a reviewable evidence pack. Evidence exports Generate CSV or PDF evidence for a reporting period, with report summaries, correspondence and ledger records. - Export report and SLA summaries. - Include researcher-visible communication excerpts. - Keep financial actors, events and amounts in the export. Program-wide exports require admin authorization. Communication logs exclude internal notes and unsent drafts. Exports support review without certifying compliance. ### Download the record for one finding. Incident dossier PDF Generate a report PDF with the finding, decisions, timeline and private postmortem. - Include the executive summary, severity and event history. - Keep postmortem details, fix references and staff sign-off together. - List attachment names, sizes and checksums in a manifest. English-only and available to authorized staff. Attachments are listed rather than bundled. This includes private content and differs from the peer-share page; the consistency digest does not certify immutability. ## Connections and analyst tools Connect existing systems and use focused investigation and document tools. ### Send the assessed findings to Vanta. Vanta evidence sync Sync assessed, unremediated reports to configured Vanta connector resources and inspect the connection’s freshness. - Verify credentials and resources through setup. - Run a manual sync or background refresh. - See synchronization times and connection failures. Requires your Vanta credentials, resources and Security access. Assessed informative reports retain accepted/no-fix context; unassessed reports are omitted. This is evidence sync, not a scan. ### Keep the report’s updates in one thread. Slack report threads Send a current report summary and event replies to the configured Security Slack channel. - Route report notifications into their thread. - Use authenticated triage, appeal and stall actions. - Ask the bot about a report and save an internal note. Requires Slack setup; bot assistance uses credits. Restricted reports receive no channel cards. Restricting an existing report removes bot content but cannot retract human replies or earlier copies. ### Let the assistant read the permitted evidence. Security Agent and MCP Use the Security Agent or an OAuth-connected MCP client to inspect reports, draft replies and take authorized actions. - Inspect configured scope, CVSS context and visible historical reports. - Fetch permitted evidence files; use triage, bounty and postmortem playbooks. - Recheck the acting member, role and report restrictions on each call. Agent-written conversation replies default to unsent drafts; a program admin can enable direct sending. Authorized status or award changes can still send their normal notifications. Writes require the acting member’s role, report access and subscription. External MCP uses OAuth read/write scopes. In-app assistance uses configured credits. ### Send the event to your own system. Security webhooks Subscribe to Security lifecycle events through account webhooks. - Receive submission, triage, assessment, assignment and SLA events. - Follow bounty approval and recorded payment events. - Use a narrow structured report payload. Payloads exclude encrypted titles, report bodies and contact fields. Webhooks deliver event metadata rather than a full report export. ### Read the sources behind the IP. IP investigation Look up ownership, routing, exposure and reputation signals from public intelligence sources. - Investigate up to ten addresses together. - See source, freshness and status for each section. - Open a report IP or paste an address in OmniSearch. Public intelligence is cached globally; this is a lookup rather than an active scan. Keyed providers can remain unavailable without configuration. Approximate location does not establish a person’s residence. ### Read why an address was flagged. Disposable email checks Check email syntax, known disposable domains and optional mail-server fingerprints. - Paste up to 25 addresses. - Inspect the reason behind each verdict. - Skip DNS for a blocklist-only check. A clean result does not prove an inbox exists or will receive mail. Results are computed on demand without persistence; account request limits apply. ### Check the breach record behind an address. On-demand breach checks Ask the assistant to check email addresses in HaveIBeenPwned and see whether passwords were among the exposed data types. - Check up to ten addresses in one request. - Read source links, breach dates and exposed data types. - Keep unknown or failed checks distinct from no known breaches. Paid accounts get 25 uncached lookups per seat each month. Results are cached for 12 hours; cached or failed checks do not spend the allowance. These checks require no mailbox verification and do not start daily monitoring. ### Hear when a team address appears in a breach. Email breach monitoring Watch known breach records for the addresses your team uses. - Watch team login emails daily on a paid account. - Add up to three verified shared or role addresses per paid seat. - Alert affected members and account admins; extra-address alerts go to admins. Daily checks use HaveIBeenPwned. Admins add extra addresses; each owner confirms by email. Alerts cover newly detected breaches added to the source within the past 30 days. Email alerts follow notification preferences. ### Open a flattened copy of the PDF. PDF sanitization Rebuild a supported PDF from page images before opening the generated copy. - Use a standalone upload or a report attachment. - Exclude scripts, embedded files, actions and text layers from the rebuilt copy. - Follow processing and retention; delete standalone utility copies when finished. PDFs up to 25 MB become image-only copies retained for seven days. Standalone raw uploads are purged after processing; borrowed report, takedown and tax evidence remains unchanged. ### Keep the notice and action history together. Takedown notices Receive phishing, malware or abuse notices through a separate form and route them to configured recipients. - Collect URL, domain, IP, brand, classification, detection time and evidence. - Give the reporter a receipt and email the configured recipients. - Let recipients acknowledge or record action through a signed link, with outcome notes and status history. Optional and off by default; invitation gating applies. Reporter organization and email are required. Signed-link recipients need no Kit account. Recorded action does not prove removal, and Kit does not run a managed takedown service. ## Give researchers a place to report. Security is included in Kit. Your team assesses findings and verifies fixes. Payments happen outside Kit. Connected services need their own setup and may charge separately. [View pricing](https://startupkit.app/pricing)