The person you talk to is the person who does the work.

What VXSec is

VXSec is a boutique access, identity, and secure automation practice. It exists for one recurring problem: growing teams accumulate access faster than they remove it. Ex-employees keep logins, contractors keep client access, OAuth grants outlive the tools they came from, automations run under personal accounts, and AI tools get connected to business data with nobody keeping an inventory.

The practice started with Google Workspace access governance and grew into the adjacent problems every audit kept surfacing: offboarding gaps, connected app sprawl, automation ownership, and admin roles that no longer match anyone's actual job.

The work behind the practice

VXSec's positioning comes from delivered projects, not a services brochure. The founder's contract work includes:

• Google Workspace access governance: Shared Drive architecture, role-based access through Google Groups, permission tiers, file ownership cleanup, and provisioning workflows.
• OAuth and API automation reliability: token handling, persistence, refresh logic, and sync reliability for a QuickBooks to Mailchimp integration on Heroku and Supabase.
• Infrastructure migration and hardening: moving PHP Laravel infrastructure and SQL data from Azure to OVH, SSL configuration, DNS, VM replication, and Linux and Windows security policy review.
• Agency internal systems: operating workflows, role-based views, onboarding, task tracking, and training structure for an ecommerce media buying agency.

Details for each project are on the selected work page.

Why founder-led works

VXSec stays deliberately small, and that is why the practice works the way it does:

• Hands-on and current. The person auditing your OAuth grants ships OAuth integrations. The person reviewing your automations builds and repairs them for clients.
• Fixed scope, in writing. A small practice cannot absorb scope drift, so scope, fee, deliverables, and exclusions are agreed before work starts. That discipline protects you too.
• Documentation as the deliverable. Every engagement produces a findings report and a change log a future hire, MSP, or auditor can pick up cold.
• No incentive to inflate. VXSec does not sell licenses, seats, or retainers-by-default, so the report recommends what the evidence supports and nothing else.

How VXSec handles your access

Giving an outside operator visibility into your systems requires trust. These are the standing rules for every engagement, and you can hold VXSec to each of them:

• MFA everywhere. Every account VXSec uses has multi-factor authentication enabled.
• Least privilege. Exports, read-only access, screen share, or temporary scoped roles are preferred over admin accounts.
• Time-boxed access. Access is granted for the engagement window and removed at the end. Removal is confirmed in the handoff.
• Approved changes only. Nothing is modified without an approved change list. Risky or dependent changes wait for explicit owner sign-off.
• Every change documented. What changed, when, why, and how to reverse it where reversal is practical.
• No password sharing. Named accounts and proper delegation only. VXSec will not accept shared credentials.
• No uncontrolled automation. VXSec does not install agents, background jobs, or automations in your environment beyond the agreed scope.
• NDA available. A mutual NDA is available before any environment details are shared.
• Clear handoff. The engagement ends with documentation, an updated offboarding workflow, and confirmation that VXSec's own access is gone.

Where VXSec is heading

The current focus is audits, lockdowns, and cleanup sprints. As the practice grows, the roadmap extends into identity security implementation: Microsoft Entra ID and Google Cloud Identity projects, SSO and MFA rollouts, conditional access, CIS-mapped secure baselines, offboarding automation, and AI agent permission governance. Advanced work is taken on when it can be delivered to the same fixed-scope, documented standard.