Auroranexis documentation
Auroranexis is designed for agency operations with organization-scoped data, role-based access control, encrypted transport and storage, and secure billing through Stripe. This page describes security controls available to customers — not internal platform infrastructure.
Security in Auroranexis is a shared responsibility between the platform and your agency. The platform provides organization isolation, role-based access, encryption, activity logging, and secure payment handling. Your agency controls who has access, which roles they hold, how API keys are managed, and how client portal users are provisioned.
Every workspace operates within a strict organizational boundary. Users, API keys, integrations, and portal accounts are scoped to a single organization. Cross-organization data access is not available through normal application or API operations.
This documentation covers customer-facing security controls: how data is scoped, who can access what, how credentials are handled, and how to report concerns. It does not describe internal platform administration, infrastructure topology, or vendor-specific operational details.
Agencies manage sensitive client data — reports, incidents, risk assessments, and operational metrics. The security model ensures that internal team members see only what their role permits, client portal users access only their assigned client, and billing data never resides in application databases.
Audit trails and activity history support internal review and compliance workflows where enabled on your plan. Security controls are designed to be understandable and actionable by agency administrators without requiring specialized security tooling.
For security concerns, vulnerabilities, or suspected unauthorized access, contact security@auroranexis.com. Include reproduction steps and impact assessment without sharing live credentials or unnecessary client data in your initial report.
Manage roles and team membership in Settings → Team. Review permissions when onboarding new staff and promptly adjust or revoke access during offboarding.
A marketing agency operating three sub-brands provisions portal users per client with white-label branding. Each portal account is scoped to a single client. The admin reviews portal user lists quarterly, removes contacts who changed roles at client organizations, and verifies no internal agency email addresses appear in client-facing portal configurations.
An automation agency rotates integration credentials after a contractor offboards. The admin revokes the contractor's Staff account in Settings → Team, deletes their personal API keys in Settings → API, and updates shared secrets in Automation → Integrations → Secrets. Activity history for the final two weeks is exported before the next automation run batch executes against production clients.
An MSP with twenty-five clients hires two junior analysts who need incident visibility but not billing or API access. The admin invites them as Staff in Settings → Team, assigns them to relevant client groups, and confirms they cannot access Settings → Billing or Settings → API. Portal users for each client are limited to the client's IT director and one backup contact.
A small IT consultancy's client requests evidence of access controls. The owner exports activity history for the relevant date range, documents the RBAC matrix showing Owner, Admin, Staff, and Viewer assignments, and confirms billing data is handled by Stripe without card storage in Auroranexis. The package supports the client's vendor review without claiming third-party certification on the agency's behalf.
A multi-region MSSP admin notices SLA configuration changed without explanation during an enterprise rollout. They open Activity, filter by the settings module and the relevant date range, and identify the user and timestamp of the change. After confirming whether the change was authorized, they restore the previous configuration, document the incident per internal policy, and align regional Admin roles before expanding portal access.
Common security issues
| Problem | Cause | Solution |
|---|---|---|
| User cannot access a module | Role or plan tier lacks the required feature permission | Verify the user's role in Settings → Team and confirm the workspace plan includes the module. |
| Portal user sees wrong client data | Portal account assigned to incorrect client | Confirm the portal account is linked to the correct client only; remove and re-invite if misassigned. |
| API key returns 401 Unauthorized | Key revoked, expired, or missing required scopes | Create a new key with appropriate scopes in Settings → API; revoke the old key. |
| Expected action not in activity history | Not all read operations are logged | Significant write and configuration actions are captured; verify filters and date range in Activity. |
Contact support@auroranexis.com for onboarding support, billing questions, or product guidance. Include your workspace name, the module you are working in, and a brief description of your goal so we can respond efficiently.
| Staff member can access billing settings |
| Billing permissions granted beyond role defaults |
| Review role assignments in Settings → Team and remove billing access from non-owner accounts. |
| Suspected unauthorized access | Compromised credentials or misconfigured integration | Revoke affected API keys, review activity history, reset passwords, and email security@auroranexis.com. |
| Client asks about SOC 2 or ISO certification | Misunderstanding of platform compliance posture | Refer to your agreement and Compliance documentation; Auroranexis describes readiness, not certification claims. |
