Authorization is the part of cloud testing most local setups quietly skip. A mock that returns
200 OK for every request will happily let code through that real IAM would deny — so the
first time your policy is actually evaluated is in production. That's the worst place to find out.
Why mocks miss policy bugs
Most emulators don't evaluate authorization at all; they assume the caller is allowed. So an
over-broad role, a missing Allow, or a deny that shadows an allow all pass locally. The
behavior you most need to test is the behavior that isn't there. (More on this in
why mocks lie.)
Evaluate real policies locally
Vyomi runs actual policy evaluation — AWS IAM semantics and Cedar for fine-grained authorization — so a denied call is really denied, locally. You can assert on it the same way you assert on any other behavior:
# A call the policy should DENY must actually raise locally
import boto3, pytest
from botocore.exceptions import ClientError
s3 = boto3.client("s3", endpoint_url="http://localhost:9000",
aws_access_key_id="limited", aws_secret_access_key="limited")
with pytest.raises(ClientError) as e:
s3.delete_bucket(Bucket="protected")
assert e.value.response["Error"]["Code"] in ("AccessDenied", "Forbidden")What this catches early
- Least-privilege regressions — a role that grew too broad fails the test that expects a deny.
- Shadowed allows — a deny that unexpectedly wins surfaces locally, not in an incident.
- Cross-tenant isolation — tenant A's credentials can't touch tenant B's resources, and you can prove it in CI.
Put it in the pipeline
Because it's all local and offline, these authorization tests run in CI with no cloud account and no secrets — see testing cloud apps offline. Authorization stops being the thing you hope works and becomes the thing you test.