Skip to content
Myra AI Workspace Administration Manual Updated · 01 Sep 2026

Customer setup

This section describes the requirements for the use of Myra AI Workspace, the recommended settings, and the responsibilities in operation. The individual steps of the setup are given in the section Initial setup.

Hardware requirements

No dedicated hardware is required on the customer side. Myra AI Workspace is delivered as a security-as-a-service solution and is operated by Myra Security. There is nothing to install and nothing to operate. For the operating mode on premises, intended for organizations with data residency requirements or isolated networks, Myra Security governs the licence, the hardware requirements, and the support during the setup.

Software requirements

The following requirements are met:

  • ☑ A current web browser for the web interface.
  • ☑ An HTTPS client or an OpenAI-compatible SDK for the programming interface.
  • ☑ A valid API key per AI provider that is used, unless only the models provided by Myra are used.
  • ☑ A mailbox per account that can receive the six-digit one-time code.

The following requirements are met in addition, depending on the use:

  • ■ An identity provider with OpenID Connect or SAML 2.0 for single sign-on, and SCIM for the provisioning of accounts and groups.
  • ■ A reachable SIEM target for the structured event per request: Splunk, Elasticsearch, Vector, or Syslog.
  • ■ A NAT instance or a proxy with a fixed egress address if the calling system works with changing addresses and an IP allowlist is used.
  • ■ A payment method accepted by the payment service provider for the plans Starter and Pro.

The following settings have proved themselves in operation:

Area Recommendation
Authentication Leave the Authentication token required checkbox switched on. The setting auth_required: false is intended for development only. Without this setting, everyone who reaches the gateway over the network sends requests and causes cost at the provider.
Tokens Issue one token per application or per person. Give every token a speaking label, an expiry, an own budget, and an own rate limit. Store the value in a key management system immediately after creation.
Budgets Set a budget on all three levels: per token, per tenant, and per gateway. Select the reset period that matches the billing period.
Rate limiting Set the sliding window limit of the gateway to the expected peak load. Give the token of a third party a tighter limit of its own.
Guardrails Switch on the tier 1 checks: jailbreak detection, keywords, and regular expressions. These checks run in process below one millisecond. Switch Fail open off for every tier 2 check as soon as the processing is subject to regulatory requirements.
PII protection Use reversible placeholders for projects that work with personal information. Extend the detection through the tenant blocklist.
EU data residency Arm eu_region_routing on every gateway that must not leave the EU. Set the EU region per tenant for AWS Bedrock and Google Vertex, and switch on the EU search engine together with the armed floor. Report every EU node under a recognized DNS suffix, because the check of the observed endpoint works fail-secure.
Routing Enter at least one fallback provider per gateway, switch on the circuit breaker, and keep a valid key for every provider of the chain.
Response cache Set cache_ttl greater than 0 on gateways with repeating requests, to lower cost and latency.
IP allowlist Restrict a gateway that is called from a known network to the CIDR ranges of that network through PATCH /admin/v1/gateways/{id}.
Logging Keep the structured request log switched on for the audit trail. Switch off payload logging per gateway or per request wherever the content itself must not be stored.
Retention Set the retention and deletion periods per tenant, project, and account according to the obligations of the organization.
Access Set up single sign-on through OIDC or SAML, and the provisioning through SCIM. Grant the role Viewer to accounts that read only.

Responsibilities in operation

The following tasks lie with Myra Security:

  • ■ Myra Security operates the instance behind the Myra Security CDN and maintains it, including the tier 2 guardrail services in the certified infrastructure.
  • ■ Myra Security resolves the errors 500 configuration_error and 500 internal_error. These errors are visible in the server-side log only. The customer supplies the request ID and the gateway slug from the request log.

The following tasks lie with the customer:

  • ■ The customer maintains the API keys of the providers and the contractual relationship with each provider.
  • ■ The customer maintains tenants, gateways, tokens, budgets, rate limits, routing rules, and the settings of the guardrails.
  • ■ The customer maintains the user accounts, the roles, and, where used, the identity provider and the SCIM connection.
  • ■ The customer rotates a lost or revoked token and stores the new value in the calling application.
  • ■ The customer decides the setting Fail open for every tier 2 guardrail and weighs availability against depth of inspection.