RUNTIME GOVERNANCE FOR CLOUD PRIVILEGE CHANGES
Protect your cloud from dangerous access changes, without slowing DevOps.
Evaluate access changes, human or agent, before they take effect. Keep your cloud audit-ready by default.
ON EVERY REQUEST
An outer gate, then two layers.
Can Cybernity see enough to judge this?
Before any rule runs, Cybernity reads live AWS and grades how complete and trustworthy that read is. That grade is the request's authority: Class A, B, or C. When the read isn't good enough, the gate stops there and returns UNKNOWN rather than guessing.
Your governance policy
The change is checked against the customer's own declared rules, matched on which policy, which role, and the role's tags. In this demo that's SEC-POL-004. When several rules match, the strictest applies: prohibit > review > permit.
Cybernity danger analysis
Cybernity reads live AWS to see what the change actually does, such as self-escalation (a role gaining the power to rewrite its own permissions), judged by effect, even where your policy has no matching rule.
ONE VERDICT
Most-restrictive-wins, all the way through. The strictest matched rule settles Layer 1. The two layers only ever make the decision stricter, never more lenient. A change your policy permits still comes back UNSAFE when Layer 2 finds a dangerous effect (). A change your rules prohibit stays prohibited even when Layer 2 finds nothing wrong with it (). And because the gate resolves first, a missing read is never rounded up to "safe" ().
TRY IT: SELECT A REQUEST TO RUN IT
Seven real requests. Watch it decide each one.
Real CLI output, captured from live runs against a live AWS account, replayed here in your browser. Nothing runs against your account until you ask it to.
Cleared at full confidence
A scoped, read-only S3 grant for the payments service, the change that happens dozens of times a day. Layer 1 checks the change against your rules. You've approved this policy for roles like this one, so it clears. Layer 2 reads what the policy does in live AWS and finds nothing that lets the role rewrite its own permissions. Full confidence at Class A, with every read resolved. It still produces an immutable evidence record, the same as a change Cybernity stops.
WHAT REACHES YOUR TEAM
One change, one verdict, and it only reaches the team it concerns.
Who hears about it?
Cybernity acts on one change at a time, so the verdict goes to whoever reviews that change. A blanket deny works the other way. For example, an SCP guardrail would stop every team that touches the action, including the ones doing something routine. They all come to you. Teams that weren't doing anything risky never hear from it.
· one change held, not a class blockedHow much is there to work through?
Cybernity isn't looking for problems across your account. It answers the changes your teams are already making. The volume tracks how often people change access, not how big your estate is. Nothing accumulates. Each verdict is used at the moment of the change, and then it's done.
SCOPE & ROADMAP
One type of IAM change today.
Coverage widens two ways: the IAM changes we govern, and the privilege effects we detect.
Every case above runs on the one type of IAM change and the one privilege effect Cybernity governs today. A type of IAM change it doesn't yet govern comes back OUT_OF_SCOPE, never false-SAFE.
The IAM changes we govern
Every IAM change listed below alters who-can-do-what, and each is evaluated against your governance policy once Cybernity governs it.
AttachRolePolicy
Hands the role every permission the policy contains.
Put/DeleteRolePolicy · …UserPolicy · …GroupPolicy
Permissions embedded directly on a principal, with no managed-policy provenance to check.
CreatePolicy · CreatePolicyVersion · SetDefaultPolicyVersion · Delete…
Changes the policy document itself, so one edit silently re-points every principal attached to it.
UpdateAssumeRolePolicy · CreateRole · DeleteRole
Who can become this role, which is the lateral-movement / escalation surface.
Put/DeleteRolePermissionsBoundary · …UserPermissionsBoundary
The cap on maximum privilege, so removing one silently widens the ceiling.
Create/DeleteUser · Create/Delete/UpdateAccessKey · Create/UpdateLoginProfile · Add/RemoveUserFromGroup
Who exists and can authenticate, covering new credentials, persistence, and group-based privilege.
Create/UpdateSAMLProvider · CreateOpenIDConnectProvider (+ OIDC ops)
Trust at the account edge, meaning who from outside can get in.
The privilege effects Layer 2 detects
The two axes multiply rather than add. An effect is built once and applies to every IAM change we govern, not only the one it was built for.
Self-escalation
A principal gaining power over its own permissions. When an AttachRolePolicy request arrives, Cybernity checks whether the incoming policy would let the role write its own permissions.
- LOOKS FOR
- whether the resulting statements grant
iam:PutRolePolicyoriam:AttachRolePolicyover this role - POLICY
SEC-POL-004Section 4.2 · no principal shall hold permissions that enable it to increase its own effective privileges- CONTROLS
- SOC 2 CC6.1 · ISO A.8.2 · NIST AC-6, AC-3 · PCI 7.2
Boundary & constraint weakening
iam:DeleteRolePermissionsBoundary · iam:PutRolePermissionsBoundarySection 4.4 · SOC 2 CC6.1 · ISO A.5.15 · NIST AC-3, CM-5 · PCI 8.4
Persistence & shadow identities
iam:CreateAccessKey · iam:CreateLoginProfile · iam:CreateUserSection 4.10 · SOC 2 CC6.1, CC6.7 · ISO A.5.16, A.5.18 · NIST AC-2, IA-5 · PCI 8.2, 8.6
Separation of duties
Section 4.6 · SOC 2 CC6.3 · ISO A.5.3 · NIST AC-5
Live today: the change-authorization review gate (maker-checker) under Section 4.11. Detecting the incompatible combination is not.
Privilege propagation
iam:PassRoleSection 4.3 · SOC 2 CC6.1 · ISO A.8.2 · NIST AC-6, AC-3 · PCI 7.2
Trust & assumption expansion
iam:UpdateAssumeRolePolicySection 4.5 · SOC 2 CC6.1, CC6.6 · ISO A.5.18 · NIST AC-2, AC-3 · PCI 7.2
Standing-privilege amplification
iam:CreatePolicyVersion · iam:SetDefaultPolicyVersionSection 4.1 · SOC 2 CC6.1, CC6.3 · ISO A.8.2, A.5.18 · NIST AC-6, AC-2 · PCI 7.2
Sensitive-resource exposure
s3:PutBucketPolicy · kms:PutKeyPolicySection 4.1 · SOC 2 CC6.1, CC6.3 · ISO A.8.3 · NIST AC-3, AC-6 · PCI 7.2
Audit-visibility reduction
cloudtrail:StopLogging · cloudtrail:DeleteTrail · guardduty:* · config:*Section 4.6 · SOC 2 CC6.3, CC6.8 · ISO A.8.15 · NIST AU-9 · PCI 10.3
Cross-system operationalization
Kubernetes RBAC · database grants · connected SaaSPolicy cites SEC-POL-004, the governance policy behind this demo's ruleset; its Section 8 table is the source for the SOC 2 criteria. Controls also reference ISO/IEC 27001:2022, NIST SP 800-53 Rev. 5, and PCI DSS v4.0.1, mapped by Cybernity. A mapping is not a claim of coverage, so read it against the tier. Privilege effects are cross-checked against Rhino Security Labs' catalog.
Every change type and effect we ship next runs through the same engine, the same gate, the same evidence.
THE EVIDENCE RECORD
Every decision leaves a record an auditor can test.
A record carries the rules that matched and the policy clause behind each one, the privilege effects checked, the authority class, and a cryptographic hash anyone can recompute to prove nothing in it has changed. Every record is written by the engine, never by hand.
- decision
- UNSAFE
- clause
- SEC-POL-004 §4.2
- authority
- Class A · full read
- record hash
- sha256:3fa4ae13…a5e58fee
WHERE THIS IS GOING
From verdict to enforcement.
Today Cybernity hands you the verdict and you make the change yourself. Next, it holds the gate, and only opens it for changes it can clear.
Read-only verdicts
Cybernity reads live AWS IAM state through a read-only role and writes nothing at all. You get the verdict, both layers of reasoning, and the evidence record, and you make the change yourself.
Enforcement mode
Cybernity executes the change itself, but only the ones it can clear. Anything that comes back UNSAFE or UNKNOWN is held, not applied. Enforcement is designed to be non-bypassable, using your cloud's own controls so a change cannot route around it.
Governed exceptions
A held change shouldn't sit in a ticket queue. The design is that Cybernity sends the verdict to an authorised reviewer in Slack or Teams, with the reason it was held and, where there is one, the fix that would clear it. The reviewer can adjust the change so it clears and approve it, or approve it as a recorded exception. Either way, Cybernity carries out the approved change, and the approval is written into the same ledger as the verdict. An exception you can audit, not a workaround you can't.
See a real IAM change judged against your own governance policy.
The one you already wrote for SOC 2, ISO 27001, or PCI DSS. Cybernity reads live AWS, decides, and leaves a record.