Customer controlled
Identity and authority
- Entra users and app roles
- Integration permissions
- AI and secret providers
Security
Security boundaries you can reason about.
GAEZLA separates human and AI identity, customer state, credentials, external services, and execution. Each boundary has a specific control, a defined owner, and a fail-closed outcome.
Architecture
One product, four distinct trust areas.
Security starts by keeping ownership visible. Customer-controlled identity and permissions do not become platform credentials, and platform authority does not become unrestricted access to enrolled systems.
GAEZLA customer plane
Separated application state
- Server-side role enforcement
- Customer-specific data resources
- Protected credential paths
Customer systems
Enrolled execution boundary
- Individual agent identity
- Local signature verification
- Encrypted appliance data volume
Configured external services
Explicit provider paths
- Customer-selected AI provider
- Customer-authorized APIs
- Customer-managed secret store
Current controls
What protects the product today.
These are active product and architecture controls. They are deliberately scoped to the systems and data they protect.
01 Active control
Human identity and access
GAEZLA validates Microsoft Entra ID tokens before API access. Signature, tenant, audience, expiry, and assigned application roles are checked server-side. A signed-in user without an assigned role is refused.
Why it mattersRole enforcement remains at the API even when a request does not come through the dashboard.
02 Active control
Customer state separation
Each customer is provisioned with its own application worker and customer-specific data resources. Communication with the platform administration plane uses a separate credential for that customer.
Why it mattersThe isolation boundary exists in the provisioned resources as well as in application authorization.
03 Active control
Agent identity and revocation
Enrolled agents use individual, cryptographically generated credentials. The standard authentication path stores a credential hash, checks revocation, and confirms that the agent remains active and trusted.
Why it mattersOne agent can be revoked without replacing a shared fleet password.
04 Active control
Secrets with an explicit home
Supported integrations can resolve secrets from customer-managed 1Password references. Where supported credentials are stored locally, GAEZLA uses authenticated AES-256-GCM encryption and refuses a new unencrypted write when its encryption key is unavailable.
Why it mattersYou can identify whether a supported connection uses an external reference or encrypted local storage.
05 Active control
Protected application entry
Browser and API traffic is served over HTTPS. API responses use restrictive security headers, and browser origins are matched against an allowlist. Operator-facing appliance services are published through Cloudflare Tunnel with service-specific Access policy.
Why it mattersThe public entry path is separate from the origin service and its access policy.
06 Active control
Verified endpoint execution
When agent-backed execution is used, the agent verifies the detached GPG signature and trusted signing fingerprint before running the workload. Missing, altered, or untrusted signatures are rejected before execution.
Why it mattersTrust is checked on the enrolled machine, at the point where execution would occur.
07 Active control
Encrypted appliance data
The optional appliance encrypts its data volume with LUKS. Bootstrap handles the passphrase through memory-backed temporary storage, and boot-time unlock checks the registered device identity before the protected data volume is opened.
Why it mattersThe protected scope is the appliance data volume.
08 Active control
Traceable security events
Requests carry correlation identifiers. Configurable user-action auditing can retain actor, operation, outcome, status, and timing while redacting sensitive-looking fields. Agent work keeps its own execution state and returned result.
Why it mattersAudit scope and capture settings show which user actions and fields are retained.
09 Active control
Bounded AI execution
Code-capable AI runs execute in a dedicated, time-bounded workload. The standard governed mode uses a read-only code sandbox, runs as a non-root user, drops Linux capabilities, prevents privilege escalation, and receives no Kubernetes service-account token.
Why it mattersA model-generated action runs inside a constrained workload instead of inheriting the appliance or control plane.
10 Active control
Scoped MCP authority
An AI run receives a short-lived identity bound to the initiating operator and operational context. Its estate-facing tools are the governed MCP search and execute surface; access is checked server-side and mutation requests become reviewable proposals rather than direct external changes.
Why it mattersThe model cannot turn its runtime access into broader estate authority or silently approve its own change.
Credential handling
A credential follows a declared path.
Different credentials have different lifecycles. Each path states what is stored and when a plaintext value is resolved for use.
Path A
External secret reference
- 01Store the vault, item, and field reference
- 02Resolve the value when the supported workflow needs it
- 03Keep the source value in the customer-managed secret store
Path B
Encrypted local credential
- 01Encrypt the supported value with authenticated encryption
- 02Persist ciphertext, not the supplied plaintext
- 03Decrypt only when the configured connection uses it
Execution boundary
The endpoint makes the final trust decision.
Agent-backed work carries a detached signature. The enrolled agent checks both the signature and the trusted signing fingerprint locally before execution. The control is enforced where the command would run, not merely where it was requested.
Prepared work Payload + detached signature
Local trust gate Signature + fingerprint verification
ValidExecute and report
Missing or invalidReject before execution
Appliance trust
Tampering fails closed.
The appliance uses a tamper-evident device seal tied to measured privileged state. An unexpected change does not quietly inherit the appliance’s prior trust.
Measure privileged state
The appliance recomputes its sealed device identity before protected data is opened.
02 · Trust gate Does the measurement match?
Unlock protected data
The encrypted data volume opens and the appliance continues as trusted.
Keep data locked
Unlock is refused, the appliance is quarantined, and normal secret and agent channels are denied.
Repair or rebuild → re-attest → restore trust
Trust returns only through an explicit recovery state and accepted re-attestation.
Precise claim: this is tamper-evident, fail-closed software protection for the appliance’s encrypted data and service authority. It is not a claim that physical alteration is impossible.
Shared responsibility
The boundary stays clear after deployment.
GAEZLA can enforce its controls only within the authority a customer configures. Identity assignments, provider choices, and integration permissions remain customer decisions.
GAEZLA protects
- Application authentication and server-side role checks
- Customer-specific application and data resources
- Supported encrypted credential storage
- AI run isolation, scoped MCP authority, and proposal gates
- Agent identity, signed-work verification, and appliance quarantine
The customer controls
- Entra assignments and identity policy
- Permissions granted to connected systems
- AI provider, model account, and secret-store policy
- Access to enrolled machines and appliance locations
External providers handle
- Cloudflare edge and managed hosting services
- Microsoft identity token issuance
- Data submitted through configured AI and integration connections
- Customer-managed secret-store availability and policy
Next step
Bring your security questions.
Book a walkthrough to review identity, AI execution, MCP authority, appliance trust, credentials, integrations, and endpoint execution against your environment.