An AI agent holds credentials to your systems, reads your documents and can take actions on your behalf. That makes it a privileged identity, and it deserves the controls you would put on any other one. This page describes how ATX Agent Hub secures the platform, the data and the agents themselves — written for the security architect who has to sign it off.
API keys, OAuth tokens, service-account keys and connection strings go into a project-scoped credential vault. They are encrypted at rest with AES-256 using KMS-managed keys, the UI is write-only — a secret is never displayed again after it is saved — and workflow nodes reference a credential by handle. At run time the secret is resolved just-in-time; it never appears in the workflow JSON, in logs or in an export.
Every workflow, knowledge base, credential, manual, chat thread and run belongs to exactly one project. Teams, clients and business units sharing a tenant never see each other's data, and membership, roles and budgets are granted per project. A knowledge base indexed for HR cannot be queried by an agent built for customer service.
Access is capability-based. Within a project people are owners, editors, runners, approvers or auditors; at platform level there are administrators, members and auditors. Builders do not need production run rights, operators do not need edit rights, and auditors can read everything without changing anything.
Promotion of a workflow to production requires an independent approver, and the requester is blocked from approving their own change. The same four-eyes principle applies to sensitive actions such as credential changes, publishing and data export. Approval decisions are bound to a specific immutable version, so what was approved is exactly what runs.
Prompt injection, off-topic requests and unsupported claims are model-level risks that network controls cannot see. ATX Agent Hub provides dedicated safety nodes — AI Guardian for harmful content, Intent Check to classify what a request is really asking for, Domain Constraint to keep an agent within allowed topics, and Fact Checking to validate claims against sources — so a high-stakes workflow can require them before anything is delivered.
Every read, write, run and configuration change emits an audit event tagged with the actor, project, environment and IP address. Run traces record each step's inputs and outputs, the knowledge-base passages retrieved, the model used and the token cost. Auditors query or export the trail from the governance console.
On the Enterprise plan the platform runs in your own Azure or Google Cloud subscription, or on-premise and air-gapped, behind your network controls. Model calls go to your own Azure AI Foundry or Vertex AI endpoints under your existing cloud agreements, so prompts and documents do not pass through a third-party SaaS.
In a project-scoped vault, encrypted at rest with AES-256 using KMS-managed keys. Secrets are write-only in the UI, referenced by handle from workflow nodes and resolved at run time, so they never appear in workflow definitions or logs.
No. Projects are hard isolation boundaries: knowledge bases, credentials, workflows and run history belong to exactly one project, and access is granted per project.
With layered controls: Intent Check and Domain Constraint nodes on the input side, AI Guardian and Fact Checking on the output side, human approval before consequential actions, and least-privilege credentials so an agent can only reach what its project allows.
ATX Institute does not currently claim a third-party certification. Enterprise customers self-host the platform inside their own certified cloud environment and apply their own controls; we support security reviews and questionnaires directly.
This site needs JavaScript for the full experience. Every page above is reachable without it.