05 / Security
Claims data is regulated data about people at the worst moment of their year. MAVALLI is built for the security and compliance requirements of insurance organizations, and the agents operate inside the controls you already run rather than alongside them.
The security question in agentic systems is not only where data is stored. It is what the agent is permitted to reach, what it is permitted to say, and whether anyone can reconstruct afterwards what it did.
All three are answered here, in that order.
01 / Access
The access model is yours. We do not ask you to adopt a second one.
01
Agents operate under credentials your organization issues, scoped to the systems, records and fields that the task requires, and revocable by you at any time without our involvement. An agent cannot see a claim that your controls would not show the person who configured it.
02
Each agent is granted the narrowest access that lets it finish its job, not the broadest that makes configuration convenient. Write access is scoped per field: an agent permitted to file an intake is not thereby permitted to edit a reserve.
03
We do not hold a parallel copy of your claims operation outside your controls. The context layer is working state reconciled continuously against your system of record, which remains the authority on every claim, and it is bounded by the same access model.
04
What may be disclosed to whom is configured per party type and enforced on the call and in the inbox. A caller is verified against the parties on the claim before anything is shared, and an agent that cannot verify does not disclose.
02 / Data
The specifics, in the terms your information security team will ask for them.
03 / Accountability
An automated action nobody can reconstruct is an automated action nobody should authorize.
Every call, message, document read and field written is recorded against the claim with the agent, the action, the inputs it worked from and the time it happened.
Calls are recorded and transcribed and correspondence is threaded, so the actual interaction is reviewable rather than summarized by the system that performed it.
Permitted speech, escalation thresholds and write-back scope are versioned and dated, so you can establish what rules were in force on the day any interaction took place.
Taken together, these answer the question that matters in a complaint, an audit or a dispute: what did the system do, on what basis, under what rules, and who was accountable for it. We treat that as a product requirement rather than a reporting feature.
The decision, and the liability, stay with your team.
The agents capture, communicate, retrieve and recommend. They do not determine compensability, set reserves, take coverage positions or settle claims, and nothing in the product is designed to let them.
A recommendation is a recommendation. It arrives with its sources attached so your adjuster can check it in seconds rather than accept it on trust, and the decision it supports remains theirs, on the record, with their name against it.
04 / Model behaviour
Most of the risk in an agentic system is linguistic rather than infrastructural.
01
Anything the system states about a claim comes from that claim's record and carries a reference to the document or note it came from. The adjuster can open the source and read the sentence, which turns verification into a two second act rather than an article of faith.
02
Where the record does not support an answer, the system reports the gap. We would rather return nothing than return something plausible. In claims, a fabricated detail is not an inconvenience, it is a liability with a regulator attached.
03
Transcription and extraction carry a confidence read. Low confidence on a field that matters escalates to a person instead of being written to the claim, and the threshold at which that happens is set with your team.
04
An agent may only say and ask what it has been configured to say and ask, per channel and per party type, including its disclosure of what it is. Outside that boundary it hands over to a person with the context attached.
05
During onboarding and continuously afterwards, your reviewers sample interactions, concentrated on escalations and low confidence events. What they find becomes a dated configuration change, so the system's behaviour is a record rather than a mystery.
Questions
The processing arrangements, locations and subprocessors for your deployment are documented and provided for review before go live, and they are part of the agreement rather than a page on a website. Internally, access is limited to what operating your deployment requires and is itself logged.
Yes. Security documentation, processing detail, retention terms and the configuration record for your deployment are provided as part of onboarding, and your team can request them earlier in the process. We would rather front-load that review than discover an objection late.
Three things, in order. It can only speak within configured bounds for that channel and party type. It can only state what the claim record supports, with a citation. And it escalates rather than improvises when it reaches a limit. Everything it did say is recorded and reviewable afterwards.
With the record. For any claim, you can show what was automated, what rules were in force at the time, what the agent said or wrote, what sources it worked from, where it escalated and which named person made each decision. That is the standard we build to, because it is the standard that is actually applied.
Immediately, by revoking its access or disabling it in configuration, without our involvement. Work in flight returns to your queues and the claim continues in your systems, because it never left them.
Next step
Send it to your security team first.
If the review happens at the start it is a conversation. If it happens at the end it is a delay. We are happy to begin there.
Get in touch