“In your tenant” means the software runs inside your firm's own Microsoft Azure environment (the same walls that already hold your email) rather than on the vendor's servers. Your deal data never leaves your infrastructure; the vendor ships code to you instead of shipping your data to them. For Arvya specifically, it also means access flows through delegated Microsoft Graph permissions (the system can only see what the granting user can see, and you can revoke it), raw emails and transcripts are read on demand and discarded rather than stored, no customer data is used to train models, and every outbound action requires a named human's approval and lands in an append-only audit log. This post translates each of those clauses into what they mean for the person who has to sign off.
Why your firm probably said no to AI tools already
If you run a PE fund or a bank, some vendor has already asked you to pipe your deal email into their cloud, and someone in your firm, probably correctly, said no. The standard SaaS AI architecture asks you to accept three things at once: your most sensitive communications leaving your control, a vendor's multi-tenant environment where your data sits alongside other firms', and terms about model training that require a lawyer to parse. For a business whose entire asset is confidential information about companies that are not yet for sale, each of those is individually disqualifying. The firms rejecting these tools are not being technophobic. They are correctly pricing the downside of a breach or a leak against the upside of a summarized meeting. The only durable answer is to change the architecture, not the assurances.
Single-tenant, in your Azure: what it actually changes
Arvya deploys single-tenant, inside the customer's own Azure tenant. In plain English: there is one installation, it is yours, and it runs on infrastructure your IT team already governs. There is no shared database with other customers, no vendor-side copy of your data, and no new data residency question: the data resides where it already resided. Your existing controls (conditional access, network policy, logging) apply to Arvya the way they apply to everything else in your tenant, because Arvya is inside them, not beside them. If the relationship ends, the deployment is decommissioned in your environment, under your control. Deployment specifics are documented at /deployments.
Delegated permissions: Arvya sees what the user sees
The second load-bearing phrase is “delegated Microsoft Graph permissions only.” Microsoft distinguishes between application permissions (a service account that can read every mailbox in the firm) and delegated permissions, where the software acts as a specific user and inherits exactly that user's access, nothing more. Arvya uses only the delegated kind. If a banker cannot open a mailbox, neither can Arvya on their behalf. There is no all-seeing service account to compromise, and access is revocable per user, instantly, by your own admin, not by a support ticket to a vendor.
What is stored, and what deliberately is not
- Not stored: raw content. Email bodies, attachments, and call transcripts are read on demand through Graph, processed in memory, and discarded. There is no warehouse of your correspondence to breach, subpoena-sweep, or leak. When Arvya needs the content again, it reads it again, from your mailbox, under the same delegated permission.
- Stored: structured metadata. The distilled facts (who met whom, when, about which deal) plus embeddings for search, the relationship graph, and the evidence excerpts behind approved CRM updates.
- Stored: an append-only audit log. Every agent action is recorded and cannot be edited after the fact. Append-only matters: a log that can be rewritten is a diary, not an audit trail.
- Never: model training. Customer data is not used to train models. Your deal flow does not improve a system your competitors also use.
Approval-first: nothing leaves without a human
Architecture governs what can be seen; approval governs what can be done. Arvya is approval-gated on every outbound action: no CRM field is written, and nothing external is sent, without a named person approving it first. After an approved write to DealCloud or Salesforce, Arvya reads the record back and shows the confirmed state (read-after-write verification), so the audit log contains not just “we attempted this” but “the record now says this, approved by this person, based on this evidence.” For a COO, that sentence is the entire risk story: the AI proposes, a human disposes, and the log proves both.
The questions to ask any AI vendor
These questions apply to every AI vendor in your pipeline, ours included. A vendor with good architecture will answer them in one sentence each; a vendor without one will answer with a paragraph about encryption at rest.
- Where does my data physically live, and who else's data lives next to it? The answer you want names your tenant, and nobody else.
- What can the system see that the individual user cannot? The answer you want is “nothing”: delegated permissions, not a firm-wide service account.
- If I revoke access today, what do you still have? The answer should be a short, specific list, and it should not include raw email or transcripts.
- Is my data used to train models? Yes-or-no question. Insist on a yes-or-no answer, in the contract.
- Can the system act without a human approving? If any outbound path is autonomous, you need to know exactly which one and why.
- Show me the audit trail for one action. Not the compliance page: an actual log entry, with the approver, the evidence, and the confirmed result.
On certifications: SOC 2 Type II and ISO 27001 are in progress at Arvya, and you should ask every vendor for their current status rather than their roadmap. But certifications attest that a process is followed; architecture determines what is at stake if it ever is not. Ask about both, and weight the architecture. The full technical detail (data flows, permission scopes, storage inventory) is at /security, written to be handed directly to your security reviewer.
