Just Approved
You set up a just approved workflow by linking chat alerts to identity roles. When a manager clicks approve, the system grants a temporary role to the user. Teams build this flow to remove standing permissions from daily work. If you skip this step, broad roles stay active all day and night. One stolen key can then let an attacker read or delete production data. How a just approved workflow operates in production A standard setup starts when an engineer needs to fix a live system. The enginee
Approved: the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a just approved workflow by linking chat alerts to identity roles. When a manager clicks approve, the system grants a temporary role to the user. Teams build this flow to remove standing permissions from daily work. If you skip this step, broad roles stay active all day and night. One stolen key can then let an attacker read or delete production data.
How a just approved workflow operates in production
A standard setup starts when an engineer needs to fix a live system. The engineer sends a request through a chat tool or ticket form. This request lists the target system, the role needed, and a short reason. The system then checks a rule list to find the right reviewer.
Next, the reviewer gets a message and checks the details of the task. Once the request is just approved, an automation script updates the cloud identity group. The engineer can now log in and run commands on the database or server. A timer also starts in the background to track the session length.
When the timer ends, the script removes the user from the identity group. The engineer loses the role and must ask again for future work. Every request, review name, and timestamp goes into a central audit log. Security teams read this log during audits to prove that a human checked the task.
What native role approvals solve and what they miss
This workflow solves the problem of permanent, unused permissions across your team. Most engineers only need production roles for a few hours each month. Removing those roles during normal days shrinks the attack surface of your cloud. It also creates a clear paper trail of who asked for a role and why.
Still, role approvals only control who can log in at the start. Once a session is just approved, the user holds the full power of that role. The native identity tool cannot see the individual queries or commands run in flight. An engineer with a write role can update one row or drop a whole table.
Approved: architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Also, revoking a role in an identity group does not always kill open sessions. Some database and server sessions stay alive until the user logs out. Teams also face review fatigue when managers must check dozens of broad role requests daily. Approving a whole role gives too much trust When a user only needs one command.
Moving from broad role checks to action controls
To close this gap, teams shift reviews from broad roles to specific actions. Instead of asking for a four-hour admin role, an engineer submits one query. The reviewer sees the exact command before it runs on the host. This makes the review fast and lowers the risk of a bad mistake.
Data protection also improves when you inspect results before they reach the screen. Even during an approved session, raw queries can return private customer details. Masking rules can rewrite emails, phone numbers, card numbers, and national IDs in results. The engineer fixes the bug while sensitive fields stay hidden during the task.
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
What does a just approved status mean for active sessions?
It means a reviewer cleared the request and the system granted the permission. The user can now log in or run the specific action for a set time.
Why do role-based approvals leave a security gap?
Role checks only happen before the user logs in to the system. They do not check or block dangerous commands after the session starts.
How can teams reduce reviewer fatigue during incidents?
Teams can auto-approve safe read queries while requiring human checks for write commands. Pairing this with data masking keeps routine checks fast and safe.