Introduction to AuthBoundry

AuthBoundry is the authority boundary for autonomous software. It answers a fundamental question that authentication cannot: What is this actor allowed to cause?

The Problem

Authentication has been solved. Your identity provider (GitHub, Okta, Auth0, Azure AD) can answer: "Who is this?"

But modern applications need more. They need to answer: "What are they allowed to do?"

That's authorization. That's what AuthBoundry does.

The Authority Model

AuthBoundry implements a rigorous separation between identity and authority:

• Identity: Who you are (from your identity provider)
• Principal: What authority-bearing subject you are
• Claims: What your identity asserts about you
• Delegation: Has your authority been delegated?
• Policy: What capabilities have been granted to you?
• Capability: What specific action do you want to perform?
• Authorization: Are you allowed to perform it?
• Evidence: Why was the decision made?

Key Principles

AuthBoundry is built on clear principles:

• Deny by default: If a policy does not explicitly allow an action, it is denied.
• Explicit capabilities: Capabilities are enumerated, not wildcard-matched.
• Tenant isolation: Multi-tenant isolation is enforced at every boundary.
• Immutable evidence: Every authorization decision is recorded and cannot be retroactively modified.
• Fail-closed: If AuthBoundry cannot evaluate a decision, the request is denied.

What AuthBoundry Owns

AuthBoundry is specifically about authority. It does not own:

• Business data or application logic
• Agent orchestration or workflow engines
• Analytics or metrics
• Secrets management or credential storage
• General enterprise IAM

What it does own is clear, explicit, audited boundaries around what applications and their actors are allowed to cause.

Next Steps

• Read Core Concepts to understand the authority model in depth
• Explore Quickstart to get AuthBoundry running
• Review Principals to learn how to define authority-bearing subjects