Beyond Security Account
You set up a beyond security account by registering your team domain and assigning role rules. Next, you link your identity provider and set up scan targets for your servers. Most engineering teams start by creating one admin profile to get tools running fast. Over time, teams share this main login or grant broad admin roles to every engineer. When roles are too broad, anyone can change scan rules or read sensitive system reports. How a beyond security account works in practice A standard bey
Cross-Account Access Delegation: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a beyond security account by registering your team domain and assigning role rules. Next, you link your identity provider and set up scan targets for your servers. Most engineering teams start by creating one admin profile to get tools running fast. Over time, teams share this main login or grant broad admin roles to every engineer. When roles are too broad, anyone can change scan rules or read sensitive system reports.
How a beyond security account works in practice
A standard beyond security account uses role rules to control what users can see and do. Admins create user profiles and assign each person to a specific team group. Each group gets permission to view scan reports, start network checks, or change target settings. Teams also link the platform to single sign-on tools so staff log in with work emails.
Once a user logs in, the system checks their group role before showing any dashboard data. Read-only users can view flaw lists and export summary files for weekly audits. Power users can add new server addresses, schedule automated checks, and mark issues as fixed. Admins control billing, manage API keys, and set password rules for the whole team.
Many teams also create service profiles for automated build pipelines. These machine profiles use static keys to trigger scans whenever developers push new app code. If you do not rotate these keys, old pipelines keep full permissions to your account. Good setup requires strict group scoping and regular reviews of both human and machine profiles.
What native account roles solve and where gaps remain
Native account roles do a great job of organizing who can use the security dashboard. They stop junior staff from deleting scan history or changing company billing details. Linking your single sign-on tool also makes it easy to remove users when they leave. For managing the portal itself, built-in group rules cover the basic needs of most teams.
Still, finding a flaw in a scan report is only half the battle for engineers. Once a report flags a broken server or database, someone must log in to fix it. Native scanner roles only govern the dashboard and do not control live server sessions. They decide who reads the report, not what commands an engineer runs during the fix.
Cross-Account Access Delegation: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
When engineers connect to production databases to patch issues, they often use shared admin passwords. The portal cannot inspect individual SQL queries or shell commands running on those target hosts. If an engineer queries a table during a fix, raw emails and card numbers appear on screen. Standard roles also cannot require peer approval before someone runs a risky delete command.
Closing the gap during live remediation work
To protect production systems during fixes, teams must govern the live session itself. Instead of handing out static database keys, teams should check every command in flight. When an engineer runs a query, data masking should rewrite phone numbers and national IDs in results. This keeps sensitive customer fields safe while the engineer fixes the underlying software bug.
Teams also need fine-grained controls for high-risk actions on production hosts and databases. A solid workflow lets engineers read system status right away but pauses dangerous write commands. A team lead can then review the exact command in chat and approve it in seconds. Every query and command gets logged with the user identity for clean audit trails.
Check database and API queries on the wire
Identity tools, roles, and network rules decide who opens a session. Setup alone cannot check what each query does or mask sensitive values in a response once a session starts. When workflows touch Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, or internal HTTP APIs, hoop.dev runs beside those services as an open-source proxy, a sidecar for your Postgres or API. It inspects requests coming in and results going back on the wire.
Your login details and client tools stay as they are while hoop.dev guardrails refuse bad deletes or drops before they run. On responses, hoop.dev data masking rewrites matched sensitive values in memory. Furthermore, hoop.dev holds SOC 2 Type II, is MIT licensed, and writes every query and decision to an audit trail that generates evidence for HIPAA, GDPR, and PCI DSS. See the source on GitHub.
Frequently asked questions
How should we structure roles in a new beyond security account?
Create separate groups for viewers, scan operators, and platform admins from day one. Give most developers read-only roles so they can check reports without changing system rules.
How do we secure API keys used by build pipelines?
Assign each pipeline its own service profile with permission to run scans on one project only. Rotate these keys every ninety days and delete unused profiles right away.
Why do we need extra controls when fixing issues found by scans?
Scanner accounts only control who can view reports inside the management portal. You need runtime session controls to audit commands and mask data when engineers fix live servers.