Security, governance and compliance
Written for the people who review us late in a deal: security, procurement, compliance and risk. Specific answers, no marketing language. If something you need is not here, ask and we will send it.
We operate inside your control environment, not beside it
We are a delivery partner, not a SaaS vendor. In almost every engagement your data stays in your systems and your cloud accounts, and our engineers work under your access model. That shapes every answer on this page: the relevant question is usually not “what is Xcelacore’s posture” but “can Xcelacore work inside ours without weakening it.”
Since 2014 we have delivered into environments with real regulatory weight — academic health systems, financial services, higher education and hospitality operations handling payment and guest data. We are used to security review as a gate, and we scope for it rather than treating it as friction.
How we work with your data
The controls that apply to every engagement, regardless of industry.
Least-privilege access
Engineers are provisioned through your identity provider against named roles, scoped to the systems the work requires, with access reviewed at phase boundaries and revoked at engagement close. Production access is separated from development access.
Data residency and minimization
Data stays in your tenancy by default. Where a non-production copy is genuinely required, we prefer masked or synthetic data, and any exception is documented, time-bound and approved in writing rather than assumed.
Secure development practice
Peer-reviewed changes, secrets held in a managed vault rather than in code or configuration, dependency and vulnerability scanning in the pipeline, and environment separation enforced by policy.
Contractual and personnel controls
Background-checked personnel, signed confidentiality obligations, and willingness to execute your MSA, DPA, BAA or security addendum rather than requiring you to accept ours.
The questions AI adds to a security review
AI introduces failure modes that traditional application review does not cover. These are the ones we design against explicitly.
| Risk | Why it matters | How we control it |
|---|---|---|
| Training on your data | Consumer and default API tiers may retain prompts or use them to improve models. | Enterprise tiers configured with training disabled and retention set to the minimum the provider allows. The configuration is documented per engagement so your reviewers can verify it. |
| Retrieval bypassing permissions | An index built once, queried by everyone, becomes a route around your access model. | Retrieval enforces the same authorization as the source system, evaluated per request and per user — never a single service identity with blanket read. |
| Prompt injection and tool abuse | Untrusted content reaching a model that can call tools or take actions. | Untrusted input treated as data, not instruction. Tool scopes narrowed to the minimum, destructive actions gated behind human confirmation, and injection cases in the evaluation suite. |
| Hallucination in a decision path | Fluent, wrong output entering a process with real consequences. | A defined human-in-the-loop boundary per workflow, citation of source material where the output is factual, and autonomy widened only on production evidence. |
| No audit trail | You cannot explain to a regulator or a customer why a system produced an outcome. | Prompt, retrieved context, model version, tool calls and output logged with correlation to the business transaction, under your retention policy. |
| Silent behavior drift | A provider updates a model and behavior changes without a code change. | Version pinning, an evaluation suite run before any promotion, and monitoring on output-quality signals in production. |
Working inside your compliance obligations
We are a service provider, so the obligation is yours and our job is to be delivered in a way that supports it.
Healthcare · HIPAA
PHI kept in your environment, minimum-necessary access, business associate agreements executed where our work touches PHI, and de-identified or synthetic data used for development wherever it is workable.
Payments · PCI DSS
Architected to keep cardholder data out of scope wherever possible — tokenization and hosted payment flows in preference to systems that expand your assessment surface.
Financial reporting · SOX
Change management, segregation of duties and evidence retention aligned to your control framework, so systems we touch remain auditable and your ITGC testing does not become harder.
Attestations and certifications
We are candid about this rather than vague: our current attestation status and any third-party audit reports are provided directly on request under NDA, and we will complete your security questionnaire, CAIQ or vendor assessment as part of the evaluation. If a specific certification is a hard procurement requirement, ask early and we will tell you plainly whether we hold it.
Due diligence answers
Will our data be used to train AI models?
No. We use enterprise API tiers configured with training disabled and provider retention set to the minimum available, and the configuration is documented per engagement so your reviewers can verify it independently rather than relying on our assurance.
Where does our data live during an engagement?
In your systems and your cloud tenancy by default. We build in your accounts and your repositories. Where a non-production copy is unavoidable, we prefer masked or synthetic data, and any exception is documented, scoped, time-bound and approved in writing.
Do you sign our MSA, DPA, BAA or security addendum?
Yes. We work to your paper as a matter of course, including business associate agreements where our work touches PHI, and we will complete your vendor security questionnaire as part of the evaluation.
How do you control what an AI agent is allowed to do?
Tool scopes are narrowed to the minimum the workflow needs, destructive or externally visible actions sit behind human confirmation, untrusted content is never treated as instruction, and the whole boundary is exercised by an evaluation suite that includes prompt-injection cases. Autonomy is widened only on evidence from production traces.
What happens to access and data when the engagement ends?
Access is revoked at close, any working copies of data are destroyed to your requirement, and you retain the code, documentation and cloud resources. Certificate of destruction is available where your policy requires one.
Can our security team review the architecture before we commit?
Yes, and we would prefer it. Architecture and data-flow review with your security team during the Plan phase is cheaper for everyone than discovering a blocker during deployment. See Plan · Build · Deliver.
Need documentation for a review?
Tell us what your process requires — questionnaire, architecture review, insurance certificates, references — and we will turn it around quickly.