Skip to main content
AQIRA
Book a demo
AQIRA

Menu

Book a demo

Security

How AQIRA handles the access you give it

What AQIRA asks for, what it keeps, and what it will not do.

Book a demoReport a weakness

Read-only, and granted in your own console

Each grant is the least the input needs, and revocable on your side.

Web and API
Nothing to grant. Reconnaissance reads public sources only; Standard and Deep send benign tests once you confirm authorisation.
Android apps
The APK you upload; the vault reads its structure as it streams in and keeps no copy.
Cloud accounts
A read-only role in AWS, trusted through an external ID AQIRA sets, or read-only access in Azure or GCP. AQIRA never asks for write access.
Code repositories
A read-scoped repository token, stored encrypted and never shown again.
Microsoft 365
Read-only admin consent in your own tenant. On-premises Active Directory is read only by a collector you enrol.
Google Workspace
Read-only admin scopes, delegated to a service account in your own admin console.

Uploads and secrets

The vault keeps no copy

Uploads are read once; pasted secrets are never shown back.

  1. Hashed as it arrives, never kept

    An Android package streams through a SHA-256 hash and a structure check. The vault never stores, decompresses or runs it.

  2. Bounded

    Uploads over 300 MB are refused, as is an archive that declares it would expand far beyond its size.

  3. Secrets are not shown back

    Credentials are digested; the console never displays a secret you gave it. A secret found in code is shown masked, with its file and commit.

What the console keeps

Findings and evidence

What an assessment produces stays in the console for your team.

What is kept
Each assessment's findings, the evidence behind them and the reports written from them, behind the sign-in and roles set out below.
Your supplier assessment
Hosting location, retention and sub-processors are answered in writing for your supplier assessment, along with your security questionnaire.

Ask for a security review through the contact form, or write to hello@aqsec.co.

Authorised targets, benign proof

AQIRA tests only what the operator has confirmed they may test; its proof is non-destructive.

  1. Confirmed before anything active

    Every active assessment and every schedule starts with the operator confirming they are authorised to test the target.

  2. Reconnaissance sends no attacks

    The passive intensity maps the attack surface from public sources; it alone needs no authorisation.

  3. Collectors stay inside their ranges

    A collector reports only on the private networks you authorise; anything outside them is refused.

  4. Benign proof

    At every intensity, proof is a unique marker the target echoes back, a measured delay, an out-of-band lookup or a read-only command's output.

  5. You can stop it

    Pause, resume or cancel any assessment from the live console; it holds or stops at the next safe checkpoint. A schedule can be paused too.

How proof works, and where every assessment stops, is in the methodology.

Who can sign in, and what is recorded

The console is by invitation; these controls apply to every account.

  1. Single sign-on

    OpenID Connect. The ID token's signature, issuer, audience and expiry are checked, a verified email address is required, and sign-out ends the provider session.

  2. Passwords

    Stored as a bcrypt hash where an account has one. Wrong address and wrong password get the same answer; the form does not reveal who has an account.

  3. Repeated guesses

    Failed sign-ins are counted per account and address; past a limit the form refuses attempts for a few minutes.

  4. Sessions and resets

    An HttpOnly, SameSite=Strict cookie that page scripts cannot read. Only the newest password reset link works.

  5. Roles

    Administration screens are for the administrator role only.

  6. Audit trail

    Sign-ins, assessments started, paused, resumed or cancelled, finding decisions and report downloads are recorded against the person. Each person sees their own history; administrators see everyone's.

What this site does with a visit

No analytics or third-party scripts, and nothing from the contact form is stored.

Scripts
No analytics, advertising or third-party scripts. Fonts are served from this site, not a font service.
The demo form
Your request goes to AQSEC's access request queue, the one the console's own sign-up uses. If that queue cannot take it, the request goes by email to hello@aqsec.co instead. A demo request starts no assessment.
The contact form
Sent to AQSEC by email, to hello@aqsec.co or, for a security disclosure, security@aqsec.co. The site stores none of it in an application database. The application uses your network address in memory to limit repeated messages. Our hosting provider also processes request metadata in security logs.
Product images
Every product screen shows the console on demo data, with example domains and fictional clients.

Reporting a weakness in AQIRA

To report a weakness in AQIRA or this site, email security@aqsec.co with enough detail to reproduce it. We confirm receipt and do not pursue anyone acting in good faith.

Do not test other customers' data or run AQIRA against a target you are not authorised to test. Machine-readable contact details are at /.well-known/security.txt.

Next step

A demo for your security review

A demo runs one assessment in the console, with demo data: the agents at work, the evidence behind each finding, and the report.

Book a demoRead the methodology