a personal ai that knows you
Ira is a personal AI built to know one person deeply and to act on their behalf. It remembers what you care about, keeps track of what you've asked it to handle, and works across your email, your calendar and the web: reading, booking, paying and coordinating with other people for you.
An AI like that is only as good as what you're willing to tell it. People share unfinished plans, private worries and the keys to their accounts only when they know exactly where that information goes and who can touch it. So we designed Ira's architecture around privacy from the first line of code.
Acting for someone raises the stakes. The model at the center will sometimes misread a request, and it will sometimes be attacked through the content it reads. We design so that when it's wrong, or fooled, the damage is bounded by code and hardware it cannot override.
This post describes how that works today: where your credentials live, how their use is recorded, how actions are approved, what happens to your memories, and how Ira decides what to tell other people. It also says plainly where you still have to trust us.
what we protect against
An AI agent becomes risky when it has three things at once: access to your private data, exposure to content written by strangers, and a way to send information out. Ira needs all three to be useful, so instead of removing any of them, we put hard limits around each one.
The system is built to keep your keys and data safe from a confused or manipulated model, from people inside Rumik, from anyone who breaks into our cloud account, and from AWS's own operators. A few things it doesn't fully protect against yet: someone who can unlock your phone, a tampered version of the app, physical attacks on server hardware, and data that is readable on our servers while it's being processed. Each of these comes up again below, where it applies.
how it fits together
Four parts matter for privacy. The Ira app on your phone holds your master key. Our servers run Ira itself: the agent, its memory and our models. Your account keys are used only inside the Credential TEE, a sealed program running on AWS. And a separate approval service, not the model, decides when Ira may go beyond what you asked.
Every time your keys are used, an entry is written to an audit log that only you can read, and anyone can check that the TEE is running the code we published.
credentials live in a TEE, not in the agent
Pulling a PNR out of a booking email requires the email's text. It does not require the OAuth token that opened the inbox, and in Ira the two never sit in the same place.
When you link a Google account, the OAuth flow completes inside the Credential TEE, so the token is created there and stays there. Inside the Ira runtime, connectors know a credential only by an opaque handle. When Ira wants an email, it sends that handle to the TEE. The TEE checks the destination against the connector's allowlist, swaps the handle for the real token, makes the call and returns the response body. Its interface simply has no call that returns a token, so there is nothing for an injected prompt to extract.
An inbox is also a master key to most of your other accounts. Before an email leaves the TEE, one-time passcodes, password reset links and magic sign-in links are removed, using deterministic filters backed by a classifier.
The TEE is an AWS Nitro Enclave: a separate virtual machine that the Nitro hypervisor carves out of an EC2 instance, with its own CPU cores and memory. It has no network interface, no persistent storage and no way to log in. Its only connection is a single vsock channel to the parent instance. Calls to Google leave through a relay on that parent, but TLS terminates inside the enclave, so the relay only ever carries ciphertext. No one at Rumik, including engineers with full access to the parent instance, can read the enclave's memory or attach a debugger to it.
We chose Nitro for credentials because small is auditable. The enclave boots one statically built program, with no shell, no package manager and nothing listening on a network. Anyone reviewing it reads one program, not an operating system.
Before the app releases anything, the enclave asks the Nitro Security Module for an attestation document. The document lists the enclave's measurements, PCR0 for the enclave image, PCR1 for the kernel and boot ramdisk and PCR2 for the application, and carries a public key generated inside the enclave at boot. It is signed through AWS's Nitro attestation PKI. The app verifies that chain, matches PCR0 to PCR2 against the published release, and seals the derived key to the enclave's public key with HPKE. Enclaves started in debug mode report all-zero measurements, so a debuggable copy can never pass.
This does put AWS's signing infrastructure inside what you trust. AWS operators have no mechanism to reach enclave memory, a design NCC Group reviewed independently in 2023, but the attestation is still AWS vouching for AWS hardware. For credentials, we think a tiny, single-purpose enclave is the right trade. Memories need GPUs, which Nitro Enclaves don't have, so they're taking a different route, described at the end of this post.
Like any hardware isolation, Nitro is designed against software attacks and privileged operators. It is not designed against someone with physical access to the server, and for that we rely on the physical security of AWS's data centers.
key hierarchy
Everything starts with a master key that the app creates on your phone. It syncs only through your platform keychain, iCloud Keychain on iPhone or Google Password Manager on Android, and never touches our servers. From it, the app derives a token-wrapping key and an audit-log key with HKDF-SHA256. Tokens rest on our servers encrypted under the token-wrapping key, and the app hands that key only to an attested TEE, for as long as a delegation lasts.
One link in this chain isn't verifiable yet. The app is closed source, and some of its security logic is delivered from our servers, so two things rest on our word for now: the master key stays on your device, and derived keys only go to a TEE that passed attestation.
delegation and the audit log
Ira keeps working after you close the app, which means the TEE needs your derived key while you're away. You decide how long that lasts: a delegation runs for anywhere from 1 to 30 days and extends each time you open Ira. Revoke it, or let it lapse, and the TEE wipes the key from memory. Until you delegate again, nothing can touch your accounts.
While a delegation is active, our servers can ask the TEE to act, and the TEE logs before it acts. For every use of a token or password it writes an audit entry, waits for the storage write to be acknowledged, and only then proceeds. If the write fails, the request fails.
Each entry is signed inside the TEE, encrypted with your audit-log key and written to Amazon S3 under Object Lock in compliance mode. For 365 days that retention can't be shortened or bypassed by anyone at Rumik, whatever their permissions. Your app is the only place those entries can be decrypted, so you can see exactly when and how each account was used.
approvals are capabilities, not chat messages
A token that can read your inbox can usually send from it too. So deciding what Ira may actually do is a separate job, and it belongs to the approval service.
When Ira wants to do something beyond the task you gave it, such as sending a message, making a booking or paying, it files a request describing the exact action. The app shows it as a native prompt outside the conversation, so text in the chat can't imitate it or answer it in advance. Your answer goes directly to the approval service, never through the model. An approval is bound to the action, the connector and the target. It can be one-time, scoped to the current task, or time-limited, and later calls must match that scope exactly.
Read-only work and actions you've already allowed proceed without interruption. The goal is friction where consent matters and nowhere else, and we expect to keep tuning where that line sits.
handling prompt injection
We don't rely on the model alone to resist prompt injection. Everything Ira reads from outside, like emails, web pages and files, is marked as untrusted. Separate classifiers, running outside Ira, check that content for injection attempts, and because they run outside Ira, a successful injection can't switch them off.
If an attack still gets through, it runs into limits the model can't change. The TEE only calls approved addresses, anything beyond your request needs your approval, and Ira can only read and talk when it speaks for you.
the browser and the secret store
When a page asks for a password or a card, Ira points to a field and to an entry in the secret store, and nothing more. A separate fill tool takes it from there: it types the value into the field, and its only output is success or failure. The model never sees the secret on the way in or on the way out.
Ira's browser agent works through a broker. It reads each page as an accessibility-tree snapshot rather than raw DOM, has no way to run JavaScript in the page, and is paused while a secret is being filled. Filled values are masked in every snapshot the model reads. Screenshots and PDF exports pass through the same check: if a secret is visible anywhere on the page, the capture is blocked.
This is the one place a secret leaves the TEE in readable form. It's encrypted on your phone before it's ever stored. At fill time the TEE logs the release, then hands the value to a worker process that types it into a remote browser running in an isolated cloud environment. For that moment the worker and the browser hold the plaintext, and what protects it is our infrastructure security rather than the TEE.
The remote browser keeps site cookies between tasks, so it can stay signed in after a delegation ends. Revoking a delegation stops the TEE from releasing secrets. It doesn't sign the browser out of the sites it has already visited.
Payments work without your card number. Connect a supported wallet and your card details stay there. When you approve a merchant and an amount, the wallet issues a card that works once, for that merchant and that amount, and that's what Ira fills in. The merchant charges a card that dies after one use, and your real number never leaves the wallet.
memory
Protecting keys doesn't protect what was read with them. An itinerary pulled from your inbox becomes part of what Ira remembers about you, and shapes later tasks. Today that memory is processed and stored on our servers, and it's worth being exact about what that means.
Data is encrypted in transit between your phone, our servers and our providers, and at rest in our databases, file systems and storage, with keys managed in AWS Key Management Service. Those keys are separate from your master key. Encryption at rest does not prevent access during processing. Ira reads memory to answer you, some conversation and task data appears in operational logs, and some tasks send relevant excerpts to outside model providers. Ira's core models are our own and run on our servers.
Your conversations and memories are never used to train our models. When a task needs an outside model, the provider is contractually barred from training on what we send. A few keep it for a short window for abuse monitoring, and the privacy policy names each one.
Inside Rumik, access to conversations and memories is limited to a small on-call group, and only for keeping the service running, debugging something you or our monitoring flagged, responding to safety reports, or legal requirements. Every view goes through internal tooling that requires team sign-in and writes an access log. The tooling masks card numbers, and it has no way to show secret-store contents or images from your camera. Each log has a defined scope: the TEE's audit log covers credential use, the staff-access log covers viewing, and neither records reads of stored memory by running processes.
Disconnecting an account doesn't remove what was already learned from it, and an expired delegation doesn't stop stored memories from being used. In the app you can inspect and edit memories, tell Ira to forget specific things, disconnect accounts or delete your account. Delete your account and the clock starts: database backups cycle out within 7 days, diagnostic and operational records within 30, and their archives within 90. Anything an outside provider holds follows its own schedule, and messages Ira already sent can't be pulled back from the people who received them.
speaking for you: the delegate
When Ira talks with a friend, or with a friend's Ira, it acts as your delegate. It knows everything your Ira knows, but it answers a different question: what should this person hear? Conversations between two Iras are visible to both owners, so the delegate treats every message as if it were said to the person directly.
Privacy researchers call this contextual integrity: information should only flow in ways that fit where it came from. If a friend's Ira asks when your train gets into Jaipur, the right answer is "6:40 am on Saturday." Your PNR, your seat, who else is on the booking and why you're travelling stay out of it.
Strangers get, at most, what's on your public profile. Friends can get day-to-day updates. Your private list names topics that never come up with anyone, and you can add notes for individual people. Every connected account has its own switch for which conversations may use it, and all of them start switched off. Ira itself can't edit any of these settings.
privacy
people who aren't friends
friends
private list
connections
preview: who's asking?
rahul's ira
when does meera's train get into jaipur?
meera's ira
reaches jaipur at 6:40 am on saturday.
Travel is shared with friends, so Ira gives the arrival time only. No PNR, seat or co-travellers.
The delegate can look things up and talk, and that's all. Bookings, payments and file changes aren't in its toolset, and if it tries to read from an account you haven't shared with that conversation, the server refuses. Change a rule mid-reply and the pending message is pulled back and rewritten under the new rule.
Two caveats. The server code that enforces these limits isn't public yet, so for now that part rests on our word. And turning a rule like "only share arrival times" into a sentence is still a model's judgment call, which can miss. Every delegate conversation is visible in your app, and since a sent message can't be unsent, catching mistakes before they go out is on us.
verifying the TEE yourself
Claims about a TEE are only useful if you can check them. The Credential TEE's source is public on GitHub. Each release is built reproducibly by GitHub Actions, so the same commit always yields the same measurement, and that measurement is recorded in Sigstore, a public, append-only transparency log under the Linux Foundation's OpenSSF.
At trust.rumik.ai, a verifier running entirely in your browser asks the live enclave for a fresh attestation document, checks its signature chain up to the AWS Nitro root certificate, compares PCR0 to PCR2 with the Sigstore entry and links you to the exact source commit. The Ira app runs the same verification before every key release.
Next on the list is the app, since it's the thing that hands the TEE its keys. We plan to publish its source, make builds reproducible so you can match the app on your phone to that source, make the security code it downloads verifiable, and let you check audit entries straight against the S3 objects they were written to.
Two gaps still rest on our policies rather than on hardware: the instant a secret is typed into the remote browser, and the time your memories spend in use on our servers. Closing the second one means encrypting stored conversations and memories under a key derived from yours, and redesigning how running services and logs touch them.
That needs a different kind of TEE. The credential enclave is deliberately tiny, and models need GPUs. For memories we're building on AMD SEV-SNP confidential VMs paired with NVIDIA's confidential-computing GPUs, the H100 and Blackwell. There, the attestation is signed by the chip makers themselves, so Ira's models can work with your memories inside hardware where neither we nor our cloud provider can see them. That's where we're headed.
We're also building a second reviewer for the delegate: a separate model that reads each outgoing message against your current rules before it's sent. It will make mistakes too, so we'll judge it on real conversations, counting both the leaks it stops and the harmless messages it blocks.
Ira should become more trustworthy as it gets to know you. The more it learns, the more of this machinery stands between your life and everyone else.
If you find a vulnerability, or a gap between this post and how the system behaves, write to security@rumik.ai.