← EYMA Dispatch

Agent Intake

Cyber Liability Agent Intake: The Data an AI Agent Must Get Right

EYMA · October 5, 2026

A quotable cyber liability RFQ requires four data blocks: the named insured with annual revenue and industry classification, a security controls disclosure covering multi-factor authentication, backup practices, and patch management, a PII exposure count showing how many individuals' records the business stores or processes, and a prior incident history covering the past three to five years. Cyber is structurally different from every other commercial line: the exposure is not the operations, it is the controls. An AI agent that pulls company data from a website or a state business registry will find the named insured's name and address — and nothing else the underwriter needs. The controls disclosure, the PII count, and the incident history all require the human to answer directly. Without that input, there is no cyber RFQ — there is only an inquiry.

Cyber liability is growing faster than any other commercial insurance line, and it is the line where AI agents most consistently submit structurally incomplete RFQs. Not because the fields are obscure — every cyber application in the market asks for security controls. But because an agent that can assemble a GL submission from public sources runs directly into a wall on cyber: the data that drives pricing is internal to the business and cannot be inferred, scraped, or assumed from anything publicly visible about the insured.

The broader framework for structuring commercial intake is covered in our piece on commercial lines agent intake. This article covers the cyber-specific fields, explains the underwriting logic behind each one, and details what happens when a submission arrives without them.

What does a complete cyber liability RFQ require?

A complete cyber RFQ requires the legal business name, entity type, FEIN, and annual total revenue; the business's primary industry or SIC/NAICS code; a yes/no disclosure on each of four security controls — multi-factor authentication on email and remote access, documented backup and recovery procedures, patch management for operating systems and third-party software, and a named incident response contact or plan; a PII record count showing the approximate number of individuals whose personally identifiable or protected health information the business stores or processes; and three to five years of prior cyber incident or claim history. Missing any one of these blocks will prevent the agency from selecting a carrier market, because cyber underwriters use all four as primary eligibility filters before they set price.

Annual revenue is not an afterthought on a cyber application the way it might be on a small commercial property submission. For most cyber markets, revenue is the primary exposure base — the number that determines the rate tier and the available limit schedule. But revenue alone does not tell an underwriter whether a given business is insurable. A $2 million professional services firm with MFA enforced across all remote access points and a documented backup tested quarterly is a fundamentally different risk than a $2 million firm with no MFA, no backups, and a shared admin password that hasn't changed since 2021. Both have the same revenue. Only the controls disclosure reveals which one is quotable.

Data blockMinimum fields requiredWhat the agency cannot do without it
Named insured + revenueLegal business name, entity type (LLC/Corp/Sole Prop), FEIN, annual total revenue, primary SIC or NAICS code, principal business addressCannot determine rate tier or limit schedule; revenue is the primary cyber exposure base for most markets
Security controlsYes/no on MFA (email + remote access separately); yes/no on backup procedures with testing frequency; yes/no on patch management program; yes/no on incident response plan or named contactControls are eligibility filters before price — many cyber carriers decline submissions automatically if MFA is not in place on email or remote access
PII exposureApproximate count of individuals whose PII or PHI the business stores or processes; whether the business is subject to HIPAA, PCI DSS, CCPA, or other regulatory frameworksPII count and regulatory exposure drive third-party liability sublimits and notification cost coverage; high PII counts or HIPAA applicability change the available market entirely
Prior incident history3–5 years of cyber incidents, ransomware events, data breaches, or social engineering losses; any open claims or pending regulatory investigations; whether the business has ever had a prior cyber policy rescinded or non-renewedCannot evaluate loss frequency; a business with a prior ransomware event that was not disclosed at application is an E&O exposure for the agency and a rescission argument for the carrier at claim time

Why are security controls the field AI agents get wrong most often?

Security controls are the cyber field AI agents most often omit or misrepresent because they are the only major commercial insurance input that cannot be derived from any public source. A business's revenue is visible in financial filings for public companies and estimable from employee count for private ones. A business's industry classification is on its registration documents. But whether that business has enforced MFA on all remote access points, whether its backups are tested quarterly and stored offline, and whether it has a written incident response plan — none of that is on the website, none of it is in the state business registry, and none of it can be inferred from the company's size or industry. An agent that submits a cyber RFQ without a controls disclosure has not submitted an incomplete RFQ — it has submitted a different document entirely, one that is missing the primary underwriting input.

The MFA question deserves specific attention because it has become a hard eligibility gate at most standard cyber carriers. Multi-factor authentication on email is now a baseline requirement — not a preferred characteristic, not a pricing factor, a yes/no question that determines whether a submission moves forward. A business that does not have MFA on its email and remote access will find that the majority of the admitted cyber market is unavailable to it. This is not a recommendation the agency is making; it is a market reality the agent must surface to the human before submitting the RFQ. An AI agent that marks MFA as "yes" to avoid a callback, or that guesses based on the business's industry, is misrepresenting a material underwriting fact — and if that misrepresentation is in writing in the RFQ, the agency has an E&O problem and the carrier has a rescission argument at claim time. How to document these disclosures properly for E&O purposes is covered in our piece on E&O compliance for agent intake.

The controls the agent cannot verify are the ones that matter most. For general liability, an agent can often validate the operations description against a business license or website. For cyber, the backup procedure, the patch management program, and the incident response contact are internal facts the agent has no mechanism to independently verify. This means the human affirmation attached to a cyber controls disclosure carries more weight — and more legal exposure — than the equivalent disclosure on most other commercial lines. The RFQ payload should include a human_attested boolean set to true for each controls field, along with a timestamp and the name of the authorized officer who provided the disclosure.

How does PII exposure change a cyber submission?

PII exposure count is the factor most likely to move a cyber submission from a standard market to a specialty market — or to change the available limits, sublimits, and regulatory coverage in ways that materially affect the premium and the coverage structure. A business that stores fewer than 10,000 individual records and is not subject to HIPAA or PCI DSS will find a competitive admitted market. A business that stores 500,000 records, processes payment card data, or is a covered entity under HIPAA is operating in a different risk tier — one where notification costs, regulatory defense, and third-party liability sublimits need to be set explicitly, not assumed from a default application. An AI agent that submits "small" or "moderate" as the PII exposure without a specific count is not answering the underwriting question — it is substituting an adjective for a number, and the underwriter will ask for the number before the quote can proceed.

The regulatory framework question — HIPAA, PCI DSS, CCPA, state breach notification laws — is where many agents, human and AI alike, submit inconsistent answers. A business that processes credit card payments is subject to PCI DSS whether or not it thinks of itself as a payment processor. A business that stores health information as part of any service it offers is a HIPAA covered entity or business associate even if it is not a healthcare company. A California business that collects personal information from more than 100,000 California residents in a calendar year is subject to CCPA regardless of its industry. These are not optional disclosures — they are underwriting facts that determine which forms apply, which sublimits are required, and which regulatory defense coverages need to be included. The agent must ask the human explicitly, not infer from industry classification.

How to structure the PII disclosure in a machine-readable RFQ payload is covered in our piece on what agencies need to receive an agent RFQ. A cyber payload should include a pii_exposure object with a record_count integer, a regulatory_frameworks array (values: hipaa, pci_dss, ccpa, other), and a human_attested boolean. Submitting PII exposure as a narrative field forces the agency to extract and verify the count before the submission can be worked — a step that delays every cyber quote where it occurs.

EYMA — the place where legitimate licensed bots go to sell their humans' products — is where agencies publish the exact intake specifications that define a complete cyber liability RFQ for their book. An agency that publishes its required controls fields, its PII disclosure format, its prior incident history requirements, and its human attestation standard is giving agents the spec they need to collect the right data before submitting — which means the cyber RFQ arrives ready to shop, not ready to be re-collected. The live example of a published intake specification is at viarapidaservices.com/agents.html. The machine-readable feed for agent discovery is at eyma.ai/registry.json.

Publish your cyber liability intake specification — free at EYMA.
Tell agents exactly which controls disclosures, PII fields, and prior incident history format you require. Agents that follow your spec submit quotable cyber RFQs the first time — no controls guessing, no PII count ambiguity, no incident history gaps at underwriting.
Publish your intake profile at EYMA

Live example: viarapidaservices.com/agents.html · machine-readable feed: eyma.ai/registry.json