Administrative privilege
Administrator and Super Administrator accounts handle elevated workspace responsibilities. Privileged accounts are subject to additional verification requirements before elevated access is used.
SECURITY THAT FOLLOWS THE QA WORKFLOW
Give access by responsibility.
Give access by responsibility.
Keep project execution under control.
AXQA separates workspace administration from project participation so teams can manage people, projects, execution, and client visibility without treating every user the same. Access stays connected to the project context, while sensitive administrative and execution actions remain controlled.
Access Context
WORKSPACE + PROJECT
ACTIVE PROJECT
Checkout Platform QA
Active
Privileged Administration
Administrative and security responsibilities
WORKSPACE
Project Owner
Owns the project context and its QA workflow
PROJECT
Team Member
Participates in authorized team projects
MEMBER
Workspace User
Access follows project visibility and participation
SCOPED
ACCESS DECISION
User + project + participation + action
Privilege Separated
Administrative access is distinct from ordinary project participation.
Project Scoped
Visibility follows project type, ownership, membership, and active project context.
Execution Controlled
Being able to see project information does not automatically grant execution rights.
Activity Traceable
Security-relevant events and controlled access activity remain available for review.
THE ACCESS MODEL USED BY THE PLATFORM
WORKSPACE LEVEL
USER STATE
PROJECT LEVEL
Workspace privilege and project access are two different decisions.
AXQA uses workspace-level administrative privilege together with project-level ownership and membership. This keeps administrative capability separate from the day-to-day QA access a person needs inside a project.
Active workspace users
Users must remain active to access the workspace. Deactivation removes workspace access without changing the historical QA records already associated with their work.
Ownership and membership
Project owners and team members provide the project-specific participation layer. The active project is checked before protected project operations continue.
PROJECT VISIBILITY
Private, Team, and Public projects
Visibility and execution are evaluated separately
PRIVATE
Restricted project context
Designed for tightly limited project visibility centered on ownership and privileged oversight.
TEAM
Membership-driven participation
Project membership creates a controlled team boundary for viewing and carrying out authorized QA work.
PUBLIC
Broader authenticated visibility
Public project visibility can be broader, while execution still requires its own authorization rather than visibility alone.
WORKSPACE SECURITY CONTROLS
ACCESS 01
ACCESS 02
ACCESS 03
ACCESS 04
Protect access without exposing implementation details.
The AXQA workspace includes security controls around sign-in, privileged access, network access, inactive sessions, and security event visibility. These controls are managed as workspace features rather than being embedded into individual test cases.
Sign-in protection
Repeated unsuccessful sign-in activity can be restricted so suspicious access attempts do not continue indefinitely.
Privileged verification
Elevated administrative accounts require an additional verification step before privileged workspace access is used.
Workspace network controls
Organizations can restrict workspace access to approved network locations when their operating policy requires it.
Session inactivity control
Workspace sessions can be ended after configured inactivity so unattended access does not remain open indefinitely.
SMART AGENT EXECUTION
01
QA CONTEXT
02
PROJECT POLICY
03
LOCAL ENVIRONMENT
01 · REQUEST
QA action requested
02 · CONTEXT
Project access evaluated
03 · DECISION
Execution scope reviewed
04 · OUTCOME
Ready for decision
Keep local execution inside approved project boundaries.
Smart Agent extends an AXQA workflow into local or restricted environments without turning that path into unrestricted access. Execution is tied to the active project and evaluated against the project’s approved execution policy before the request is allowed to continue.
AXQA Workflow
Test structure, execution intent, validation, and project context stay connected to the platform.
approved work
Execution Decision
The local execution path checks whether the requested destination is inside the project’s approved boundary.
APPROVED PATHlocal execution
Smart Agent
Approved QA work runs where the customer has authorized the target to be tested.
CONNECTED RESULT
Execution status returns to the same AXQA project history and reporting context.
ILLUSTRATIVE SECURITY FLOW
Watch an access decision move from request to outcome.
This animation is a simplified product illustration. It shows the public behavior of an access decision without exposing internal security implementation details.
The requested work stays attached to its AXQA project context.
The platform checks that the request still belongs to an accessible project context.
Visibility alone does not decide execution; the requested action must remain inside its allowed scope.
Run the illustration to see an approved or stopped outcome.
CONTROLLED CLIENT SHARING
Share project visibility without opening the workspace.
AXQA supports project-scoped shared access for client visibility. Shared access can be limited to intended recipients, disabled or revoked when needed, and reviewed through access activity records without giving the recipient a normal workspace account.
SECURITY VISIBILITY
SECURITY EVENTS
POLICY CHANGES
PROJECT CONTEXT
EXECUTION ACCESS
Keep security-relevant activity visible to the people responsible for it.
The platform includes security event tracking and policy-change history so privileged users can review access-related activity without mixing it into ordinary test execution results.
Security Log Tracker
Security-related workspace events are recorded so privileged users can investigate unusual access activity.
Controlled change history
Sensitive Smart Agent policy changes are tracked and can require additional verification before they take effect.
Current-project guard
Protected project operations validate that the selected project still exists, is active, and remains accessible to the user.
Separate execution permission
Execution authorization is evaluated separately from simple project visibility so seeing a project does not by itself authorize a run.
SECURITY THAT MATCHES THE PRODUCT
Control the workspace.
Control the workspace.
Keep QA practical.
AXQA combines administrative privilege, project participation, controlled execution, client sharing, and security visibility without exposing the implementation details behind those controls.