A new vendor lands on your desk and the questionnaire writes itself: where does it run, what does it touch, where does data go, who can see it, how are secrets held, and what is the AI actually doing. This page answers each one in the language of a control, names the mechanism, and is honest about what is generally available, what is a deployment option, and what we are not claiming. Lift the answers straight into your CAIQ or SIG.
You know how it usually goes. The business wanted the tool live last month. Legal is still waiting on the vendor to explain how encryption keys are rotated. Your questionnaire has nine items parked in "vendor to respond," and each follow-up costs another week. Deals slip on a single control nobody can get a straight answer about. We wrote this page, and the reference behind it, to close that gap. Every question below is answered as a control, with the mechanism named, so your review is a read rather than a chase.
CrossConnect installs on your own servers, on-prem or in your own cloud account, and the system of record is a PostgreSQL database you own. Network data does not leave your boundary as a side effect of running the product. The only paths out are ones you switch on yourself: an outbound webhook to a tool you operate, or a prompt to an AI model provider you choose. Disable both and the platform makes no outbound product calls beyond the egress paths you configure.
The complete data-flow, from acquisition to output, is documented in the Data Flow Architecture, and the full control set is in the Security & Architecture Reference.
CrossConnect reads device state over management protocols, the same reads an operator runs from a jump box. It does not span a port, mirror traffic, or inspect packet payloads. Writing to a device is a separate, human-approved, logged action, never something collection does on its own. The credentials it uses are scoped read-only and held encrypted.
Exactly what is read per protocol is enumerated in the Data Collection Reference.
Sign-in federates to your identity provider over SAML or OIDC. No separate password store to manage, deprovisioning follows your IdP, and the platform never becomes a shadow account directory.
SAML · OIDCRoles separate read, operate, and administer. Access maps to groups by site, role, or service, and the assistant inherits the caller's role: it cannot return data the person is not cleared to see.
least privilegeMulti-tenant installs keep each tenant's data partitioned. No tenant, and no assistant query, can cross the boundary into another tenant's network.
partitionedProgrammatic access uses scoped, revocable API keys, issued per integration and bounded to least privilege. Keys are stored hashed and can be rotated or revoked without downtime.
scoped · revocableDevice credentials, API keys, and other secrets are encrypted at rest with AES-GCM under an envelope scheme: a data key per secret, wrapped by a master key that stays on your server and is held in memory only for the moment of use. Keys rotate without downtime, and a startup guard refuses to boot on a weak or default master key, so a misconfigured deployment fails closed rather than running unprotected.
Each audit entry is chained to the one before it by hash, so removing or editing an entry after the fact breaks the chain and is detectable on verification. The log captures who did what and when across the platform: sign-ins, configuration reads, approvals, exports, and every AI prompt with the records it retrieved and the answer it returned. You can verify the chain end to end on demand, and export it for your own retention or external notarization.
The conversational layer answers only from your own records, cites them, and says "I don't know" when they cannot support a claim. It will not invent a device, address, or relationship. It honors the caller's role, logs every prompt and retrieved record, and it never executes a change. You choose the model provider, or run a built-in mode that calls no external service at all.
Answers cite the exact records. If the data cannot back a claim, it returns "I don't know" rather than guessing, and it never fabricates an entity.
cite or refuseIt explains a problem and hands you the command, but it does not apply changes, not even with a confirm step. There is no path from a chat answer to a device write.
no executionEvery query runs under the caller's role and cannot surface data they are not cleared for. Prompt, retrieved records, and output are all written to the audit log.
RBAC · loggedPoint the assistant at the model provider you approve, or run the built-in mode that calls no external model service. The grounding and logging rules hold either way.
BYO model · offline modeflowchart LR Q["Someone asks a question"] --> CC["CrossConnect"] CC --> WHO["Confirms who they are
with your own company sign-in"] WHO --> SEE["Shows only what their role is allowed to see"] SEE --> ANS["A clear answer with its source,
or an honest 'I don't know'"] CC --> LOG["Every step written to a record
that cannot be quietly changed"] classDef app fill:#173a6b,stroke:#0f2a4f,color:#ffffff; classDef good fill:#1797b3,stroke:#0d7d90,color:#ffffff; classDef ext fill:#ffffff,stroke:#9aa8c0,color:#173a6b; class CC app; class ANS,LOG good; class Q,WHO,SEE ext;
Token-level anatomy and the cost model of AI usage are documented in the API Cost Analysis.
Have a CAIQ, SIG, or a custom questionnaire? The Security & Architecture Reference pre-answers most of it, with a control crosswalk. Send the rest and we will answer plainly.
Written for reviewers: controls, crosswalks, ports, and data flows you can lift straight into an assessment. View in the browser or download the PDF.
Most of your questions are already answered in the Security & Architecture Reference. For the rest, we would rather give you a defensible answer than wave our hands. Send the questionnaire, get straight answers back, and close the control that would have slipped the deal. It runs inside your boundary, on your data, with your choice of AI provider or none.
