Security Architecture Overview

AXQA applies security across multiple layers, from dedicated customer infrastructure and workspace isolation to project permissions, authentication, execution controls, network policies, and security monitoring.
The architecture is designed so that security controls remain active throughout the complete QA workflow rather than depending on a single authorization layer.

Why it matters

• Protects customer data at infrastructure, workspace, project, and execution levels.
• Reduces the impact of a compromised credential or misconfigured workflow.
• Provides multiple independent security controls across the AXQA platform.

When to use it

• When evaluating AXQA security architecture.
• When preparing an internal security review.
• When explaining AXQA security controls to enterprise customers.
•  When reviewing how different AXQA security features work together.

Core concepts

• Dedicated Workspace – A customer-specific AXQA instance running in its own server environment.
• Workspace Isolation – Separation between different AXQA customers.
• Project Isolation – Logical separation between projects inside a customer workspace.
• Authentication – Verification of user, client, or Smart Agent identity.
• Authorization – Validation of whether an authenticated identity can perform an action.
• Network Policy – Rules that control which systems AXQA or Smart Agent can communicate with.
• Security Monitoring – Logging and visibility into security-relevant activity.

How it works

1. Each AXQA customer operates inside a dedicated workspace.
2. Projects inside the workspace remain separated through project-level access controls.
3. Users authenticate before accessing protected platform functions.
4. Project and execution permissions are validated before protected actions are processed.
5. Network controls protect outbound API and Smart Agent execution.
6. Browser and application security controls protect the web interface.
7. Sensitive credentials are protected separately from normal test data.
8. Security-relevant events are recorded for monitoring and investigation.

How to use it

Step 1: Understand workspace isolation

Each customer subscription operates inside its own AXQA server environment.

Customer data and execution activity are not stored inside another customer's AXQA workspace.

Step 2: Use project-level access controls

Inside the workspace, Projects provide additional logical separation.

Project visibility, ownership, membership, and execution authorization determine which users can access project data.

Step 3: Protect user access

AXQA provides multiple user-security controls including:

• Authentication
• Two-Factor Authentication
• Login-attempt protection
• Rate limiting
• Single-device session protection
• Automatic logout
• IP Whitelisting

Step 4: Protect testing execution

Server execution and Smart Agent execution apply their own security controls.

These include:

• Project authorization
• Outbound request validation
• Smart Agent device authentication
• Network Allowlists
• Request signing
• Replay protection

Step 5: Monitor security activity

Use the Security Log Tracker and related audit information to investigate:

• Unauthorized requests
• Protected configuration changes
• Rate-limit activity
• Network-policy changes
• Authentication failures
• Security-sensitive operations

Best practices

• Use multiple security layers instead of depending on one control.
• Keep administrative accounts limited to authorized personnel.
• Enable restrictive network policies when possible.
• Review security logs regularly.
• Use individual user accounts instead of shared credentials.
• Review Project and Shared Access permissions periodically.

Common mistakes

❌ Assuming workspace isolation replaces project permissions.
✔ Workspace isolation and project authorization protect different security boundaries.

❌ Assuming authenticated users can perform every action.
✔ AXQA validates authorization separately from authentication.

❌ Ignoring security monitoring after configuration.
✔ Review security activity and configuration changes regularly.

Security & permissions

• Security configuration is restricted according to the corresponding administrative function.
• Project-level controls remain active even inside a dedicated customer workspace.
• Security controls are enforced server-side where applicable.
• Smart Agent cannot bypass AXQA project authorization or its Network Allowlist.
• Security architecture should be combined with appropriate customer operational policies.

Related documentation

• Security & Client Isolation
• Security Log Tracker & Live Security Monitoring
• Login Attempts Blocker & Rate Limiting
• Two-Factor Authentication, Sessions & Auto Logout
• IP Whitelist Security
• Smart Agent Security Model