Where is presentation data stored and processed?
Storage and processing follow the selected deployment architecture. In a fully private design, documents, extracted text, prompts, models, generated assets, and presentation files remain inside customer-controlled infrastructure.
Security review should map every system that can receive content: the Presenton application, language model, image provider, web-search service, database, object storage, logging stack, backups, and support tooling. External services can be disabled or routed through approved endpoints where the deployment supports that configuration.
Presenton does not use a generic certification claim as a substitute for this architecture work. Enterprise teams should validate their chosen topology, retention policy, provider agreements, and operational controls against internal policy and applicable regulation before production rollout.
How are authentication and authorization handled?
Enterprise deployments can integrate centralized identity and define administrative, creator, reviewer, and service access according to the rollout design.
Identity requirements commonly include SAML or OIDC single sign-on, providers such as Microsoft Entra ID, Okta, or Keycloak, API keys for service workloads, role-based permissions, and workspace separation. The final integration depends on deployment edition and customer identity architecture.
Use least privilege: separate platform administration from content creation, scope service credentials to the smallest required workflow, rotate secrets, revoke inactive users, and keep high-risk configuration changes auditable. Authentication is only one control; storage and API authorization must follow the same model.
How can outbound network access be controlled?
A private deployment can restrict egress to approved model, image, storage, and update destinations—or remove external connectivity when compatible local dependencies are available.
Connected deployments may route requests to Azure OpenAI, another approved provider, or a private OpenAI-compatible endpoint through enterprise networking. Air-gapped deployments require local models, mirrored container images, internal fonts and assets, and an offline update procedure.
Document required destinations and ports before launch. Use firewall policy, proxies, private endpoints, internal registries, certificate management, and monitoring appropriate to the environment. Test failure behavior when a dependency is unavailable so the application fails visibly rather than bypassing policy.
What the platform supports
Enterprise capabilities
SSO and identity integration
Plan SAML or OIDC integration with the enterprise identity provider selected for the deployment.
Role-based access
Separate administrators, creators, reviewers, and service workloads using governed permissions.
Auditability
Capture generation activity and relevant administrative events in the approved logging architecture.
Private networking
Deploy behind customer network boundaries and route providers through approved paths.
Data residency
Select infrastructure and storage locations that align with organizational requirements.
Retention and backups
Control artifact lifecycle, backup policy, deletion, and recovery within your environment.
Decision matrix
Security responsibility by deployment model
Confirm the exact boundary during architecture review; this matrix is a planning guide.
| Control area | Managed cloud | Customer-hosted | Air-gapped |
|---|---|---|---|
| Application operations | Presenton-managed | Customer-managed | Customer-managed |
| Model routing | Configured service options | Customer-approved endpoints | Local endpoints only |
| Presentation storage | Managed service storage | Customer-selected storage | Internal storage |
| Outbound network | Service-managed | Customer policy | No external route |
| Updates | Continuous service updates | Controlled rollout | Offline staged rollout |
From evaluation to production
Enterprise security review process
- Step 01
Classify the data
Identify source documents, users, sensitivity, residency, and retention requirements.
- Step 02
Map the architecture
Document every application, model, storage, network, and observability component.
- Step 03
Configure controls
Implement identity, permissions, secrets, egress, logging, backups, and lifecycle policy.
- Step 04
Validate and operate
Run security testing, restore tests, change management, monitoring, and periodic review.
Evaluation checklist
Questions to resolve before rollout
- Data-flow and threat-model review
- Identity-provider and access-role design
- Provider and subprocessor approval
- Network and outbound allowlist
- Logging and retention specification
- Backup and recovery test
- Vulnerability and update ownership
- Incident-response contacts
Buyer questions
Frequently asked questions
Does Presenton require sending data to a public AI model?+
No single provider is mandatory. Presenton supports configurable providers, including Ollama and OpenAI-compatible endpoints. A private design must also review image, search, storage, and telemetry configuration.
Can Presenton run in a private network?+
Yes. Customer-hosted deployments can run inside private cloud, VPC, or on-premises networks. Required ingress, egress, storage, and identity integrations are defined for the selected architecture.
Is Presenton certified for a particular compliance framework?+
Do not infer a certification from deployment controls. Contact Presenton for the current security and compliance documentation, then evaluate the deployed system against your own obligations.
Can anonymous telemetry be disabled?+
The open-source deployment documents a setting for disabling anonymous telemetry. Enterprise teams should verify all observability and outbound settings in the exact release they deploy.
Primary references
Product capabilities and enterprise terms can change. Confirm current edition, deployment, security, support, and contractual details with Presenton before making a purchasing decision.
