Vexta's Audit Log and Active Session Management

Who is logged into a shared Vexta instance right now, and can that access be cut off the moment a contractor's engagement ends or a laptop goes missing? Yes: Vexta writes every login, logout and password change to an audit log, and an owner or admin can see every active session on the instance and revoke any of them on demand. Vexta is VITI Security's agentless, AI-augmented vulnerability scanner and pentest platform, and because one instance is often shared across a team or handed from tester to tester on an engagement, knowing who has access right now and being able to end it instantly matters almost as much as the findings themselves.

Why a shared scanner needs an audit trail

A vulnerability scanner that a whole team logs into is a different kind of asset than one person's laptop tool. Testers rotate on and off engagements, contractors get temporary access for a single job, and the instance itself often holds live client findings that have not been through a report yet. If something changes, a finding gets marked differently, a license gets deactivated, someone's password gets reset, the team needs to know who did it and when, without digging through server logs or guessing.

That is the gap an audit trail closes. Instead of a shared login with no accountability, every account-level action on a Vexta instance leaves a timestamped record, and that record is visible to the people responsible for the instance rather than buried somewhere only an administrator with shell access could find it.

It also matters for the kind of reporting a client or a program owner sometimes asks for. If a client wants to know who on the team had access to their environment's scan data during an engagement, a straight answer beats a reconstruction from memory.

What does Vexta's audit log actually record?

Vexta logs successful logins, failed login attempts, logouts, password changes, license activations, license deactivations, and session invalidations, each with its own timestamp. A run of failed login attempts followed by a success is visible in the same place as a routine end-of-day logout, so a lead reviewing the log can spot a pattern that looks like guessing rather than a legitimate sign-in.

Visibility is scoped by role. An owner or admin sees every audit event across the whole instance, every user's logins, every password change, every license action. A regular team member only sees the events tied to their own account. That split means a team lead gets the full picture needed to run the instance, while an individual tester is not exposed to everyone else's account activity.

How do active seats work?

Alongside the audit log, Vexta keeps a live list of active sessions, each one tagged with the IP address, browser or device it is coming from, and when it was last active. That turns into a real-time roster: who is signed in, from where, and how recently, rather than a static list of accounts that exist.

An owner or admin can revoke any session on that list; a regular member can only revoke their own. In practice that means a lead can end a contractor's session the moment an engagement wraps, or shut down a login from an unrecognized device, without waiting for a password reset to take effect or asking anyone to log out voluntarily. The revoke action itself validates the session identifier strictly, so a malformed or tampered identifier cannot be used to affect a session it should not touch.

Sessions also use a sliding timeout: every authenticated request nudges the expiration forward a little, so a hunter mid-scan is not logged out just because a scan is running long. A quiet session still ages out on its own, and a restart of the Vexta service does not sign everyone out either, so a scan that outlives a routine restart does not turn into a login scramble for the whole team.

What happens when someone changes their password?

A password change on Vexta always requires re-entering the current password first, whether it is a team member changing their own credentials or an admin account changing its own. Once that succeeds, every other active session tied to that account is invalidated immediately, and the change itself is written to the audit log.

That makes a password change do double duty. It is not just a new credential; it is an implicit sign-out-everywhere for that account, which is exactly what you want after a suspected credential leak or when handing a shared admin account over to someone new. Exact settings and role behavior can vary slightly by license; see plans on the pricing page for specifics.

Key takeaways

What Vexta's audit log and active seats give a team running a shared instance: