Our default deployment puts the agent inside your cloud account, reading through your permission model, writing to your systems, logging to your infrastructure. We operate the software. We don't hold a copy of your data — which removes most of what a security review is normally worried about.
This decision is made during the Sprint, not after contracting, because it changes the architecture rather than a setting.
| Model A — Your cloud (default) | Model B — Our cloud | Model C — Air-gapped | |
|---|---|---|---|
| Agent runs in | Your AWS / Azure / GCP account | Our isolated tenant | Your network, no egress |
| Model inference | Your provider account, zero-retention | Our provider account, zero-retention | Open-weight, on your hardware |
| Data at rest with us | None | Encrypted, defined retention | None |
| Logs and audit trail | Your systems | Ours, exportable to you | Your systems |
| Our access | Time-bound, you grant and revoke | Operational, role-based | Escorted sessions only |
| Data residency | Wherever your account is | Region of your choice | Your premises |
| Typical for | Most enterprises | Teams without cloud ops capacity | Regulated, sovereign, or classified |
Table 1 — Deployment postures. Model C accepts lower model capability in exchange for total isolation; we'll be explicit about that trade-off.
Model A shown. The only outbound traffic is the inference call — and in Model C, not even that.
The agent receives scoped access to the specific objects its workflow needs — not a service account with the run of your CRM. Every write operation is enumerated per deployment and defaults to drafts and internal notes.
The agent cannot surface information to a person who couldn't already access it in the source system. We test this explicitly before launch rather than assuming the integration inherited it.
An inference call carries the records needed for that one task, with configurable redaction of identifiers before it goes. Bulk export to a model provider isn't something the architecture can do.
Credentials live in your secret manager, rotated on your schedule. In Model A we never possess them at all — the agent reads them at runtime from a store you control.
What the agent read, what it produced, who approved it, what they changed — written to your logging infrastructure, queryable and exportable for a regulator, a works council or an internal review.
Categories you define — legal threats, grievances, safety complaints, anything you nominate — are detected and routed to a named person before any generation happens.
Disable the agent and every process works exactly as it did before. Nothing in your operations comes to depend on it being available, by design.
You get a named list of every engineer with access. All are background-checked employees, not subcontractors. Access is granted by you, scoped to the engagement, and revoked when it ends.
In Model A the only third party touching your data is the model provider you selected. Everything else is yours.
| Party | Purpose | Data touched | Retention |
|---|---|---|---|
| Model provider | Inference for the reasoning step | Minimised task context | Zero, contractual |
| Your cloud provider | Compute the agent runs on | Already yours | Your policy |
| IntegrateX | Building and operating the software | Access during engagement | No copy retained (Model A) |
| Anyone else | — | None | — |
Table 2 — Model A sub-processors. New sub-processors require your written approval, with 30 days notice.
A vendor implying certifications they don't hold will fail your review later, more expensively.
We act as processor; you remain controller. A DPA with standard contractual clauses is available and signed as a matter of course. In Model A and Model C there is no onward transfer, because the data never leaves your environment.
We deliberately build assistive systems — drafting, summarising, orchestrating — rather than systems that make decisions about people. That is a large part of why our deployments avoid the heaviest obligations. Your legal team should confirm classification for your specific configuration; we provide the technical documentation for that assessment.
IndiaNIC operates an ISO 27001-aligned information security programme; your reviewer can request the current certificate status and scope directly, and we'll answer precisely rather than gesture at a badge. Where you require a SOC 2 report from the operator of a system, Model A resolves it — the operator of record is you.
HIPAA, PCI-DSS, financial-services regulation and public-sector frameworks each impose specific requirements. We'll tell you honestly whether we've delivered under that regime before. Where we haven't, we say so and scope accordingly rather than claiming coverage.
You're welcome to pen-test the deployment — it runs in your environment, so it's your system to test. We'll support the exercise and remediate findings in the agent code at no charge within the engagement.
Prompt injection is a real and unsolved class of problem, and any vendor claiming immunity is overstating. Our answer is architectural rather than clever: retrieved content is treated as data, never as instructions; the agent's permitted operations are a fixed enumerated list rather than something a prompt can extend; and the highest-consequence actions require a human. A successful injection can make a draft wrong. It cannot make the agent send money, delete records or email a customer, because those capabilities don't exist in the deployment.
Retrieval is scoped per request to the identity the ticket or record belongs to, and there is no persistent memory shared across requests where cross-contamination could accumulate. This is one of the specific tests we run before launch, and the test suite is yours after handover so you can keep running it.
Where our engineers sit is separate from where your data sits. In Model A the system runs in your account in your chosen region, and our access is remote, logged and revocable by you — the same posture as any offshore engineering team touching production. Where a regulation requires that no non-resident may access the data at all, Model C with escorted sessions is the configuration that satisfies it, and we'll say so plainly rather than argue the point.
Notification within 24 hours of becoming aware, written into the DPA, with the facts as known rather than a reassurance. Worth noting the structural point: in Model A a breach of IntegrateX doesn't expose your data, because we don't hold it. The realistic exposure is our access credentials — which is exactly why access is time-bound, individually named and revocable by you without our involvement.
Yes to both, and they're in your repository anyway. There is no obfuscated component, no encrypted binary, no "proprietary core" you can't inspect. Your security team can read every instruction the agent operates under. We think a vendor asking you to trust a black box inside your own systems is asking for something unreasonable.
Three to five working days for a standard framework, because we keep completed answers on file. Send it before the Sprint and we'll complete it during that week at no cost and no obligation — it's the single most effective way to compress your timeline, since contracting stops being sequential with discovery.
No NDA needed for most of it, and no obligation attached. If your reviewer wants to assess us before your business team talks to us, that's a sensible order.
We'll complete it during the Sprint week at no cost, so your security review and the technical question happen at the same time instead of one after the other.