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 monitor our systems continuously rather than reactively, and we hold our own practices against recognized industry standards rather than grading ourselves on our own curve.
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 keys are managed through a dedicated key management service with regular rotation, so that even in the rare event a key were compromised, it wouldn't remain a long-term vulnerability sitting quietly in our systems.
Access Controls
- Single sign-on (SSO) and multi-factor authentication (MFA) are available on eligible 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.
| Framework | Status | Scope |
|---|---|---|
| SOC 2 Type II | In progress | Security, availability, confidentiality |
| ISO/IEC 27001 | Planned | Information security management |
| GDPR | Compliant | EU/EEA personal data |
| CCPA / CPRA | Compliant | California consumer privacy |
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 small set of vetted providers to deliver the service, each bound by data-processing terms consistent with our obligations to you. Keeping this list genuinely short is deliberate, 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 the service.
| Provider | Service | Region |
|---|---|---|
| Amazon Web Services | Cloud infrastructure and storage | US |
| Stripe | Payment processing | US |
Vulnerability Management
We scan our systems for vulnerabilities on an ongoing basis, patch according to a risk-based schedule that prioritizes severity over convenience, and run periodic penetration tests using both internal review and external perspective. 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:
Frequently asked questions
Quick answers to common questions.
Data is stored on AWS infrastructure. Depending on your plan and region, you may be able to choose a US or EU storage region to match your own residency requirements.
Yes, throughout its entire lifecycle. TLS 1.2 or higher protects it in transit, and AES-256 protects it at rest, meaning there's no point where your data exists unprotected.
No, not for anything that matters. High-stakes actions, sending, scheduling, paying, always require your explicit approval before Kira actually executes them. This is enforced in how the product works, not just stated as a policy.
Yes. Customers on eligible plans can request our security overview, sub-processor list, and applicable attestations by contacting support@kiraai.ai directly.
Please email support@kiraai.ai with details. We acknowledge reports promptly and won't pursue good-faith research conducted under our disclosure guidelines.
We'd rather be accurate about where we genuinely stand, GDPR and CCPA/CPRA compliant today, with SOC 2 actively in progress and ISO 27001 planned, than imply attestations we haven't actually completed yet. As those certifications complete, this page will be the first place they're reflected.