v4.2.0

Use cases

For teams who test boundaries for a living, and respect them the rest of the time.

Security already has a word for everything. Most of those words turn out to mean exactly what you were trying not to think about. Here's how each one works with a consent-first policy engine.

13
use cases, all of them scoped
0
engagements without a safeword
100%
of out-of-scope findings left alone
1
entrance. We counted.
featured · red vs blue, with a safeword

Red team · offence

a-2210

scope: web, api · excludes prod-db

Blue team · defence

b-4417

scope: detect, respond · may say stop at any time

  1. exercise ex_77 started · roles signed for this window

Offensive security

Pen-testing

In security
Authorized attempts to get in, so you find the weak spots before someone else does.
With iamsec
Nobody gets in without a signed scope, written rules of engagement and an agreed safeword. Out of scope stays out of scope, however interesting it looks.
$ iamsec engagement open --scope web,api --exclude prod-db --safeword RED

✓ 0 findings outside the signed scope

Offensive security

Red-blue teaming

In security
One side attacks, one side defends, and everyone learns something.
With iamsec
Roles are agreed before anything starts and swapped only through a new proposal. When both sides sit down afterwards and talk about how it went, that's purple teaming. We call it aftercare.
$ iamsec roles assign --red a-2210 --blue b-4417 --swap requires_proposal

✓ 403 on every mid-exercise role swap

Defensive security

Brute-force protection

In security
Rate limits and lockouts for anyone who keeps trying the same door.
With iamsec
No means no, including on the ten-thousandth attempt per second. Persistence isn't a credential, and asking again doesn't move it closer to yes.
$ iamsec policy set auth.retry --after-deny never --lockout permanent

✓ Retry-After: never

Defensive security

Social-engineering defense

In security
Training people not to hand over access just because someone asked nicely.
With iamsec
Flattery isn't a factor. Neither is urgency, a nice smile or “but I came all this way.” The engine evaluates the signed policy, not the charm.
$ iamsec factors list --accepted # charm: not listed

✓ 0 grants issued on compliments

Defensive security

Honey pots

In security
Decoys that look tempting so you can see who goes for them.
With iamsec
Sweet-talk detection. Anything that sounds too good, too fast, with too few questions gets logged, flagged and politely ignored. Also: calling the policy engine “honey” doesn't get you access. We checked.
$ iamsec decoy deploy --bait 'no limits, no questions' --alert on_touch

✓ “honey” is not a credential · 0 grants issued

Defensive security

No backdoors

In security
No hidden way in that bypasses the front door's controls.
With iamsec
We've been asked, repeatedly, sometimes by people with very nice letterhead. The answer is still no. Every entrance goes through the policy engine, and the engine has exactly one entrance.
$ iamsec audit entrances --list # 1 result

✓ Entrances: 1. Exceptions: 0.

Identity

Zero trust

In security
Never trust by default; verify every request.
With iamsec
Zero trust, plenty of chemistry. Every request is verified, including the ones you're excited about. Especially those, actually.
$ iamsec policy set trust.default deny --verify every_request

✓ Chemistry: high. Implicit trust: 0.

Identity

Privilege escalation

In security
Gaining more access than you were given. Usually the thing you're trying to stop.
With iamsec
Escalation only happens by invitation. Step-up needs a fresh, explicit affirmation. Nobody gets promoted just by wanting it harder.
$ iamsec step-up request --scope contact.firm --needs affirmation:fresh

✓ Escalations without an invite: 0

Identity

Role-play-based access control

In security
RBAC: permissions come from the role you hold, not who you are.
With iamsec
Roles are costumes, not entitlements. You can be anyone you've agreed to be for ninety minutes, and the role goes back on the hanger when the window closes.
$ iamsec role wear --as 'pirate captain' --window 90m --inherit none

✓ Roles that outlived their window: 0

Identity

Three-headed authentication

In security
Kerberos: tickets issued by a trusted third party, named after a three-headed dog.
With iamsec
Kerberos, but every head has to say yes. One enthusiastic head and two hesitant ones is a no. Tickets are short-lived and non-transferable, like all the best ones.
$ iamsec kerberos issue --require-heads 3/3 --ttl 90m

✓ Quorum: unanimous or nothing

Operations

Hot standby

In security
A warm replica, ready to take over the moment it's needed.
With iamsec
Ready doesn't mean presumed. Failover to the standby still needs a fresh affirmation, because being available is not the same as being asked.
$ iamsec failover --to standby-02 --require affirmation:fresh

✓ Presumed failovers: 0

Operations

Responsible disclosure

In security
Report a vulnerability privately so it can be fixed before anyone exploits it.
With iamsec
Tell us your vulnerabilities. We'll handle them gently, keep them between us, and never use them against you. Hard limits are never shown as a list of weaknesses.
$ iamsec disclose --private --audience security@ --embargo 90d

✓ Vulnerabilities used against the reporter: 0

Operations

Multi-tenancy, with boundaries

In security
Many customers share one platform, each isolated from the others.
With iamsec
Lots of tenants, one building, firm boundaries. Every tenant's limits are isolated, and noisy neighbours get a policy, not a key.
$ iamsec tenant create --isolation strict --shared-limits none

✓ Cross-tenant grants: structurally impossible

Your use case isn't listed?

Propose it. We'll review it, narrow it, and send it back with a time box. That's not us being difficult. It's the product.

Propose a use caseSee what we defend against