Identity security for AWS, Azure and Google Cloud.
Most breaches start with an identity that had more permission than anyone remembered granting. GuardVault inventories every cloud identity, scores the privilege it really exercises, and puts the excess behind just-in-time approval — in the same control plane that already brokers your SSH, RDP and database sessions.
What it does
Discover every identity
Humans, roles, service principals, service accounts and workload identities — inventoried continuously across every connected account, subscription and project.
Measure the permission delta
Compare what each identity is granted against what it has actually used, from CloudTrail, Entra sign-in logs and GCP Recommender. Right-size on evidence, not guesswork.
Close escalation paths
Graph iam:PassRole, role-assignment write and setIamPolicy chains so an identity can never quietly promote itself to owner.
Broker what's left
Standing admin becomes an eligible role behind GuardVault JIT approval — recorded, hash-chained and replayable like any other privileged session.
Three clouds, one model
Each provider is read through native, read-only APIs. GuardVault never stores a long-lived secret: AWS is assumed via role with an external ID, Azure via workload identity federation, GCP via service-account impersonation.
Amazon Web Services
Identity sources
- IAM users, roles, groups and inline/managed policies
- IAM Identity Center (SSO) permission sets and assignments
- Access Analyzer external-access findings
- CloudTrail last-used data for the permission delta
- STS assume-role chains across accounts
Access granted
- · SecurityAudit + ViewOnlyAccess managed policies
- · iam:GenerateServiceLastAccessedDetails
- · access-analyzer:List*
- · organizations:List* (for multi-account discovery)
Microsoft Azure / Entra ID
Identity sources
- Entra ID users, groups and service principals
- Managed identities and their role assignments
- Azure RBAC role assignments across subscriptions
- Privileged Identity Management (PIM) eligible vs active roles
- Sign-in logs for staleness and MFA coverage
Access granted
- · Directory.Read.All (Microsoft Graph, application)
- · RoleManagement.Read.Directory
- · AuditLog.Read.All
- · Reader on each subscription in scope
Google Cloud
Identity sources
- IAM principals: users, groups, service accounts
- Allow-policy bindings at org, folder and project level
- Service-account keys and their age
- Workload Identity Federation pools and providers
- Policy Analyzer + recommender for unused permissions
Access granted
- · roles/iam.securityReviewer
- · roles/recommender.iamViewer
- · roles/cloudasset.viewer
- · roles/logging.viewer
How it runs
Connect
Grant a read-only role, app registration or impersonated service account. No keys leave your cloud.
Collect
The GuardVault engine runs inside your perimeter and pulls entitlements, activity and policy on a schedule.
Correlate
Cloud identities are joined to your directory and to GuardVault session history for one identity timeline.
Act
Findings turn into policy changes, JIT elevation or a revocation, tracked in the tamper-evident audit chain.
The collector is the same GuardVault engine you already deploy for session brokering. It runs inside your network, holds the cloud trust locally, and pushes only findings and identity metadata to the control plane — never credentials, never workload data.
Detections out of the box
Every finding maps to a remediation you can execute from the console — or hand to the policy engine to enforce automatically.
| Finding | Severity | Clouds | Remediation |
|---|---|---|---|
Excessive permissions The identity is granted far more permissions than it has exercised in the observed window. | warning | aws · azure · gcp | Right-size to the used set, or move the delta behind a JIT request. |
Standing administrative access Permanent Owner / AdministratorAccess / roles.owner binding with no expiry and no approval gate. | critical | aws · azure · gcp | Convert to eligible-only (PIM) or broker it through GuardVault JIT approvals. |
Privileged identity without MFA A human identity holding privileged roles authenticates with a single factor. | critical | aws · azure · gcp | Enforce phishing-resistant MFA and require step-up on privileged sessions. |
Dormant identity No sign-in or API activity for over 90 days while permissions remain live. | warning | aws · azure · gcp | Disable the principal and archive its bindings. |
Long-lived access key A static access key or service-account key older than the rotation window. | critical | aws · gcp | Replace with workload identity federation, then delete the key. |
Unbounded cross-account trust A role or app registration can be assumed from outside the organization boundary. | warning | aws · azure | Add an external ID / tenant restriction, or scope the trust policy. |
Privilege escalation path The identity can grant itself higher privilege through iam:PassRole, role assignment write or setIamPolicy. | critical | aws · azure · gcp | Remove the escalation permission or gate it behind dual approval. |
Unowned non-human identity A service principal or service account with no registered owner in GuardVault. | info | aws · azure · gcp | Assign an owning team so rotation and review have an accountable party. |
Mapped to your audits
Every detection is mapped to the identity controls of the frameworks your auditors ask about. The console scores each framework control by control and exports the evidence as CSV.
Section 1 — Identity and Access Management hardening for AWS accounts.
Section 1 — Entra ID identity, MFA and privileged role governance.
Section 1 — IAM principals, service accounts and key rotation.
AC / IA control families — least privilege, separation of duties, authenticators.
A.5 and A.8 organisational and technical access-control controls.
CC6 logical access criteria — provisioning, least privilege and credential hygiene.
Requirements 7 and 8 — need-to-know access and strong authentication.