Security & Compliance

Our Approach to Security

Security is built into how Kira is designed, not added at the end. Every module, from the Email Agent reading your inbox to the Call Agent handling a phone conversation, was built with the assumption that it would eventually be trusted with genuinely sensitive information, and designed accordingly from the start rather than retrofitted once that trust was already extended.

We follow the principle of least privilege throughout the platform, meaning access to anything is scoped as narrowly as it can be while still letting the system do its job, never broader "just in case." We encrypt data by default, not as an optional setting someone has to remember to enable. We hold our own practices against recognized industry standards rather than grading ourselves on our own curve, and we are actively building out continuous monitoring and alerting as part of our security roadmap.

Where a lot of security pages stop at abstract promises, phrases like "bank-level encryption" or "enterprise-grade security" that don't actually tell you anything concrete, we'd rather show you what these commitments actually look like inside the product itself, and be specific about where we currently stand versus where we're still working to get to.

What This Looks Like in Practice, Not Just in Policy

Abstract claims like "access controls" and "least privilege" mean something concrete in how Kira actually behaves day to day, and it's worth spelling that out rather than leaving it as legal language you have to take on faith.

Any action an agent takes that could matter, sending an email, placing a call, scheduling something, moving money, requires your explicit approval before it happens. This isn't a policy commitment sitting in a document somewhere separate from the product, it's built directly into how the agents function. An Email Agent can draft a reply, but it cannot send that reply without you reviewing it first, unless you've explicitly configured it otherwise for lower-stakes routine cases. A Call Agent can place a call, but the decision to launch an outbound campaign at scale requires deliberate setup on your part, not something that happens by default.

This matters because a lot of "AI safety" language in the industry describes intentions rather than actual system behavior. We'd rather point directly to how the product is built than ask you to simply trust a paragraph of policy prose.

Infrastructure

Kira runs on Amazon Web Services (AWS), inside data centers that maintain leading physical and environmental security controls, the kind of physical safeguards, restricted facility access, environmental monitoring, redundant power, that would take years and significant resources to build independently from scratch.

Production systems are kept fully isolated from development and testing environments. This separation matters more than it might initially sound, it means a bug introduced while our team is actively building or testing a new feature has no path to accidentally affect the live systems actually running your account. Access to infrastructure itself is restricted to a deliberately small group of people who genuinely need it, and every single access is logged and reviewed, rather than trusted implicitly once granted.

Encryption

• Data in transit is encrypted using TLS 1.2 or higher, applied to every connection by default, whether that's a message being sent through Email Agent or a call being routed through Call Agent, not something you have to opt into.
• Data at rest is encrypted using AES-256, one of the strongest widely available encryption standards, meaning your data remains protected even in the unlikely event that physical storage was somehow compromised.
• Secrets and encryption keys are stored outside application code and are never committed to source control.

Access Controls

• Single sign-on (SSO) is available on Business plans, letting teams enforce their own identity requirements rather than relying solely on password strength.
• Internal access to customer data is limited specifically to staff who need it for support or operations, and every access is logged, meaning there's an actual audit trail rather than an unverifiable assurance that access is limited.
• Role-based access controls govern what each team member can see and do inside your workspace, so a support agent troubleshooting an issue doesn't have the same reach as an account administrator.

Certifications and Frameworks

We align our program with widely recognized frameworks and pursue independent attestation as we scale. Being transparent about exactly where we stand today, rather than implying a level of certification we haven't yet reached, matters more to us than looking further along than we actually are.

Rather than repeating this table across multiple pages where the details can drift out of sync over time, one page updating while another gets forgotten, this page is the single source of truth for our certification status. Every other page on the site that references certifications links back here instead of maintaining its own copy.

Sub-Processors

We rely on a set of vetted providers to deliver the service, each bound by data-processing terms consistent with our obligations to you. Every additional processor is another party with some level of access to think carefully about, so we only add one when it's genuinely necessary to a feature you use, and this table reflects the providers actually in use in production today, not an aspirational subset.

A note on WhatsApp: the official integration above (Meta's WhatsApp Business Cloud API) is separate from the optional "personal WhatsApp" linking feature offered in some modules, which connects an owner's own WhatsApp account as a companion device rather than calling a Meta-operated API. We're reviewing how that feature should be described here and will update this table accordingly.

Where Kira connects to Google APIs, such as Gmail, our use and transfer of information received from those APIs to any other app adheres to the Google API Services User Data Policy, including the Limited Use requirements. See the full statement on our Privacy Policy.

• Google API Services User Data Policy↗
• Privacy Policy — How We Disclose Personal Data→

Vulnerability Management

We scan our systems for vulnerabilities on an ongoing basis and patch according to a risk-based schedule that prioritizes severity over convenience. We welcome reports from independent security researchers through our Responsible Disclosure process, treating good-faith research as a genuine asset to our security posture rather than a nuisance to manage.

Incident Response

We maintain a documented incident-response plan and a 24/7 on-call rotation, meaning a security concern doesn't sit unaddressed simply because it surfaced outside business hours. If a security incident affects your data, we'll notify you without undue delay and within the timeframes required by applicable law, we'd rather over-communicate early with incomplete information than stay silent while we investigate fully. Contact support@kiraai.ai for security questions of any kind.

Requesting Documentation

Eligible customers can request our full security overview, sub-processor list, current attestations, and a Data Processing Addendum by contacting support@kiraai.ai. We're glad to walk through any of this in more depth for teams doing formal vendor security review as part of a procurement process.

Standards and References

Our security program is informed by, and measured against, the following recognized standards and authorities:

• AICPA — SOC 2 reporting framework↗
• ISO/IEC 27001 — Information security management↗
• NIST Cybersecurity Framework↗
• CISA — Cybersecurity & Infrastructure Security Agency↗