Your data, your tenant, your keys
Enterprise Genesys programs need clear answers on data ownership, secrets, authentication and operational responsibility. This is the Streamvane security model — full artifacts follow in discovery and proposal appendices.
Data ownership
Nothing is funneled into a vendor cloud
Unlike hosted-only connector models, the primary store is client-controlled. Your metrics, secrets and workers all live in infrastructure you own.
- Operational KPI documents in your metrics store, in your region
- Connection strings and endpoints in your Azure Key Vault
- Reactive Engine and export workers in your Azure subscription
- Turn it off and the data is still yours
Authentication & access
Least privilege on every surface
Every entry point into the platform is authenticated, scoped and least-privilege by default. There is no shared super-user, no standing broad access, and no plaintext secret anywhere in the stack — each surface has its own credentials, its own scope and its own blast-radius limit, so a compromise in one place cannot cascade into another.
| Surface | Pattern | Why it matters |
|---|---|---|
| REST read APIs | JWT / token auth, profile-scoped | Consumers only ever see the KPI families they're entitled to |
| Genesys API access | OAuth client-credentials per Genesys best practice | A tightly scoped Genesys app, rotatable without a redeploy |
| Admin & infrastructure | Cloud RBAC; least privilege in runbooks | No standing broad access — every change is attributable and auditable |
| Secret retrieval | Key Vault references — never plaintext in config | Credentials never live in source, images or app settings |
| Event ingress (Service Bus) | Namespace-scoped identity / SAS | Ingress can read its own subscription and nothing else |
| Outbound feeds | Per-destination credentials + egress allowlist | A compromised feed cannot reach an arbitrary endpoint |
Authentication patterns are confirmed against your identity provider and security policy during onboarding — these are defaults, not limits.
Shared responsibility
Who owns what
Security reviews move faster when the responsibility boundary is explicit from day one. In the embedded model the client owns the infrastructure and the data end to end, while Tessovia owns the application logic during the engagement. Nothing below is ambiguous, and nothing sits in a grey area where an incident has no owner.
| Layer | Client | Tessovia |
|---|---|---|
| Cloud subscription governance | Owns | Advise |
| Genesys org administration | Owns | Advise |
| Secrets & key rotation | Owns the vault | Defines references |
| Application code & configuration | Reviews | Owns (during engagement) |
| KPI definitions & connector mapping | Approves | Builds |
| Connector payload accuracy | Joint | Joint |
| Downstream consumer security | Owns | — |
In the managed-PaaS model, isolation and residency responsibilities shift accordingly and are agreed explicitly at scoping.
Controls
Network, data scope, observability & compliance
Network & deployment
Private endpoints / VNet integration per policy, TLS on all egress, and Service Bus peek-lock with dead-letter monitoring so nothing is silently lost in transit.
PII & operational scope
Focused on operational KPIs — queue, agent and routing metrics — not call recordings or transcription. PII scope is bounded and documented in discovery.
Secrets & key management
Every credential resolves from your own Key Vault at runtime. Rotation is a vault operation, never a redeploy, and no secret is written to source, image or config.
Observability & audit
Application Insights on hosts, feed success/failure logs, schema versioning and reconciliation reports against Genesys baselines where contracted.
Resilience & recovery
Durable, ordered ingress with dead-letter handling means events are never dropped silently — KPIs can be recomputed and backfilled from the event log after any incident.
Compliance
GDPR honoured via the privacy process; ISO 27001 / SOC 2 are stated only when verified. We never claim a certification we don't actually hold.
Security FAQ
What InfoSec usually asks
Can InfoSec review the architecture before purchase?
Yes — an architecture PDF and security FAQ are provided after the intro call, ahead of any commitment, so your team can assess data flows and controls before money changes hands.
Do you store Genesys credentials?
Only in your Key Vault, which you control. Nothing sensitive is embedded in configuration or source, and credentials can be rotated at any time without a redeploy.
Can we restrict outbound feed URLs?
Yes — egress allowlists are configurable so feeds only ever reach approved destinations, and a misconfigured or compromised feed cannot exfiltrate to an arbitrary endpoint.
Where does the data physically live?
In the cloud region you select, inside your own subscription. In the embedded model it does not transit or rest in a Tessovia-controlled cloud at all.
Do you support SSO / SAML and our identity provider?
API access uses token / JWT auth that integrates with your IdP, and any admin surface federates with your SSO/SAML during onboarding — no separate identity silo.
How are changes audited?
KPI definitions and connector mappings are versioned and reviewable, and infrastructure changes flow through your own RBAC and pipelines — so every change has a clear owner and an audit trail.
Send it to your security team
Request the architecture PDF and security FAQ, and we'll support your InfoSec review before any commitment.
Streamvane by Tessovia · Azure · AWS · GCP · Your data, your keys