The safest architecture is the one where we hold nothing.
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.
- Training on your data
- Never
- Where it runs
- Your cloud, by default
- Data we retain
- None, in Model A
- Air-gapped option
- Yes, open-weight
- Questionnaire turnaround
- 3–5 working days
Three postures. You choose before we build.
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.
Exactly what leaves your boundary, and when.
Model A shown. The only outbound traffic is the inference call — and in Model C, not even that.
What's enforced, not promised.
- ACCESS
Least privilege, read-first
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.
- IDENTITY
Your permission model wins
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.
- MINIMISATION
Only the task's context leaves
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.
- SECRETS
You hold the credentials
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.
- AUDIT
Every action traceable
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.
- CONTAINMENT
No-go topics never reach a model
Categories you define — legal threats, grievances, safety complaints, anything you nominate — are detected and routed to a named person before any generation happens.
- REVERSIBILITY
One switch, and it's off
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.
- OUR PEOPLE
Named, vetted, time-bound
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.
The short list, because there is genuinely a short list.
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.
Stated plainly, including the gaps.
A vendor implying certifications they don't hold will fail your review later, more expensively.
GDPR
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.
EU AI Act
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.
ISO 27001 & SOC 2
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.
Sector regimes
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.
Penetration testing
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.
The ones that come up in every review.
What stops the agent being manipulated by content it reads?
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.
Can the agent leak one customer's data to another?
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.
Your engineers are in India and the UAE. What about data localisation?
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.
What happens if you have a breach?
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.
Can we see the source code and the prompts?
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.
How quickly can you return our security questionnaire?
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.
Request the pack before you commit to anything.
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.
- No NDA
Architecture & data-flow document
- No NDA
Standard DPA with SCCs
- No NDA
Sub-processor register
- On request
Completed CAIQ / SIG-lite responses
- On request
Insurance certificates & entity details
- On request
Incident response & notification policy
- At contracting
Named engineer list & vetting attestations
Send us the questionnaire before you send us a brief.
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.