Guardrails and boundaries

Policies grant access. Guardrails and permission boundaries limit it: they never grant anything themselves, they only cap what other policies grant. A request needs an allow from every layer that applies, and a Deny in any layer wins. See How a request is decided.

Guardrails

A guardrail is a policy attached to the whole organization. It binds every principal in it, owners included. An organization without guardrails behaves as if it had one that allows everything.

Typical uses:

• forbid deleting anything without MFA;
• keep everyone out of a project that holds production data, except a break-glass role;
• allow API calls only from your office and VPN ranges.

no-deletes-without-mfa.json

{
  "Version": "2026-10-08",
  "Statement": [
    { "Sid": "Everything", "Effect": "Allow", "Action": "*", "Resource": "*" },
    {
      "Sid": "DeletesNeedMFA",
      "Effect": "Deny",
      "Action": ["compute:Delete*", "network:Delete*", "network:ReleasePublicIp"],
      "Resource": "*",
      "Condition": { "BoolIfExists": { "auth:mfa": false } }
    }
  ]
}

Note the first statement: a guardrail must allow what it doesn’t forbid, or it denies everything else. And because auth:mfa is only true for console sign-ins with a second factor, this guardrail means deletes happen in the console, never with an access key.

tebib iam policy create no-deletes-without-mfa -f no-deletes-without-mfa.json
tebib iam simulate -p user/u-0123456789ab -a compute:DeleteVM -r 'trn:tebib:compute:lab-neo-1:p-0123456789ab:vm/*' -c auth:mfa=false
tebib iam guardrail attach no-deletes-without-mfa

Caution

A guardrail takes effect at once for everyone. Check it with tebib iam simulate (or the console’s IAM → Access check) before you attach it.

You can’t lock yourself out: the guardrail actions themselves (iam:*Guardrail*) are exempt from guardrails, so an owner can always detach one with tebib iam guardrail detach <guardrail ID>.

Permission boundaries

A permission boundary is one policy set on a single user, service account or role. That principal’s policies then grant only what the boundary also allows. Use it to let someone create IAM principals without being able to create one more powerful than intended, or to make sure an automation key can never do more than read, whatever gets attached to it later.

tebib iam boundary set --principal service-account/sa-0123456789ab --policy ReadOnly
tebib iam boundary list
tebib iam boundary remove --principal service-account/sa-0123456789ab

Set one when you create the principal with --permission-boundary:

tebib iam role create ci --trust-policy trust.json --permission-boundary ReadOnly

At a glance

	Policy	Guardrail	Permission boundary
Grants access	Yes	No	No
Applies to	Who it’s attached to	Everyone in the organization	One principal
Binds owners	If attached to them	Yes	If set on them
Typical owner	Team leads	Organization owners	Whoever delegates IAM