The Authority Boundary

Identity and authority are not the same. Your identity provider answers who you are. AuthBoundry determines what you're allowed to cause.

Identity ≠ Authority

Identity (Your Provider)

Answers the question: "Who is this?"

  • • GitHub user login
  • • Service principal
  • • API token
  • • OAuth session

You delegate this to your identity provider (GitHub, Auth0, Azure AD, etc.)

Authority (AuthBoundry)

Answers the question: "What are they allowed to do?"

  • • Capabilities (invoice.read, invoice.refund)
  • • Principals (agent_123, user_456)
  • • Policies (what each principal can do)
  • • Delegations (authority transfers)

You own this. AuthBoundry helps you manage it.

The Authority Model

1. Identity

Who the subject is. GitHub user, service principal, API token. Your identity provider asserts this.

2. Session

Is this identity still authenticated? Sessions are time-bound and revocable.

3. Principal

What authority-bearing subject exists in your system. A principal is a first-class entity that can hold authority. One identity can have multiple principals; one principal maps to exactly one identity.

4. Claims

What does the identity assert? Email, name, groups, roles. Claims are immutable assertions from your identity provider.

5. Delegation

Has this principal's authority been delegated to another? Delegations are explicit, temporary, and audited.

6. Policy

What authority has been granted to this principal? "This principal can perform this capability." Policies are versioned, audited, and durable.

7. Capability

What specific action is requested? invoice.read, invoice.refund, document.delete. Capabilities are explicit and enumerable.

8. Authorization

Is this principal allowed to perform this capability? AuthBoundry evaluates policies and returns ALLOW or DENY.

9. Evidence

Why was this allowed or denied? Evidence is a durable, immutable record of every authorization decision. Why did it happen? What policy granted it? Who changed what?

Clear Boundaries

AuthBoundry Owns

  • ✓ IdentityWho exists
  • ✓ SessionsAuthentication lifecycle
  • ✓ PrincipalsAuthority-bearing subjects
  • ✓ ClaimsIdentity provider data
  • ✓ DelegationAuthority transfers
  • ✓ PolicyWhat is allowed
  • ✓ AuthorizationEnforcement decisions
  • ✓ Authority AdministrationManaging the system
  • ✓ Audit & EvidenceImmutable records
  • ✓ Boundary EnforcementAt the gateway

AuthBoundry Does NOT Own

  • ✗ Business DataYour customer data
  • ✗ Application LogicWhat your app does
  • ✗ Agent OrchestrationScheduling/workflow
  • ✗ Workflow EnginesState machines
  • ✗ AnalyticsBusiness metrics
  • ✗ General IAMEnterprise directory
  • ✗ Secrets ManagementVault/credential store

The Developer Workflow

1

Connect

Attach your application to AuthBoundry

2

Discover

AuthBoundry learns what your app can do

3

Review

You review the proposed authority model

4

Approve

Approve and activate policies

5

Enforce

AuthBoundry enforces authorization at the boundary

6

Inspect

Review evidence and audit logs

The Principle

Your application remains responsible for what it does. AuthBoundry determines whether the actor is authorized to cause it.

  • Your app: "user_123 wants to refund an invoice"
  • AuthBoundry: "Does user_123 have invoice.refund?"
  • Your app: "Yes/No. Proceed/Stop."

Authorization is not your application's problem. Authority is AuthBoundry's.

Ready to explore the code?

Get Started →