agentic-identity-broker / internal
AGENTS.md68 starsChanged 10 days agoMITView on GitHub
Read the source and nearest child AGENTS.md before you select types, interfaces, or patterns. Paths are relative to the repository root unless a section states otherwise. internal/domain/AGENTS.md | Domain layer rules, data models, error types, zero-infra imports internal/domain/id/AGENTS.md | Strongly typed entity IDs, code generation, type catalogue internal/ports/AGENTS.md | Port interface catalogue (read internal/ports/*.go directly for contract) internal/adapters/AGENTS.md | Adapter map, cross-adapter ban, storage/encryption/HTTP internal/extproc/AGENTS.md | Standalone ExtProc service and its narrow shared-package exceptions Use the root AGENTS.md for the…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,700 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository45 other files it gives its agents.
- AGENTS.mdAGENTS.md
- infra/AGENTS.mdAGENTS.md
- tests/AGENTS.mdAGENTS.md
- web/AGENTS.mdAGENTS.md
- infra/CLAUDE.mdCLAUDE.md
- internal/CLAUDE.mdCLAUDE.md
- tests/CLAUDE.mdCLAUDE.md
- web/CLAUDE.mdCLAUDE.md
- agents-md-housekeepingSkill
- aws-crypto-goSkill
- jwx-guide-v4Skill
- simple-englishSkill
- speckit-agent-context-updateSkill
- speckit-analyzeSkill
- speckit-checklistSkill
- speckit-clarifySkill
- speckit-constitutionSkill
- speckit-convergeSkill
- speckit-git-commitSkill
- speckit-git-featureSkill
- speckit-git-initializeSkill
- speckit-git-remoteSkill
- speckit-git-validateSkill
- speckit-implementSkill
- speckit-planSkill
- speckit-specifySkill
- speckit-tasksSkill
- speckit-taskstoissuesSkill
- speckit-agent-context-updateSkill
- speckit-analyzeSkill
- speckit-checklistSkill
- speckit-clarifySkill
- speckit-constitutionSkill
- speckit-convergeSkill
- speckit-git-commitSkill
- speckit-git-featureSkill
- speckit-git-initializeSkill
- speckit-git-remoteSkill
- speckit-git-validateSkill
- speckit-implementSkill
- speckit-planSkill
- speckit-specifySkill
- speckit-tasksSkill
- speckit-taskstoissuesSkill
- agentic-workflowsSkill
The file
We split this AGENTS.md into the rules it gives an agent
11 rules. About 0 are common, 4 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 17
Use the root AGENTS.md for the constitution, ADR index, API contracts, and feature selection.
- Very specific: line 41
Read internal/adapters/AGENTS.md for existing subsystem factories and shared helpers.
- Distinctive: line 43
Before you add a cross-layer dependency, read the port contracts and applicable ADR.
- Very specific: line 136
Add handlers to internal/app/handlers.go.
- Very specific: line 156
Read coding-standards/LOGGING.md before you add or change a log call.
- Distinctive: line 164
Use the root TDD requirements.
- Very specific: line 165
Put _test.go files beside the package.
- Very specific: line 166
Assertions: Use testify. Use require for fatal preconditions.
- Very specific: line 167
Subtests: Use t.Run("description", ...).
- Very specific: line 170
HTTP: Use httptest.NewRecorder() and httptest.NewRequest().
- Distinctive: line 175
Keep adapter records in adapter packages.
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Backend — Hexagonal Architecture (internal/)
Read the source and nearest child
AGENTS.mdbefore you select types, interfaces, or patterns.
Paths are relative to the repository root unless a section states otherwise.
Child AGENTS.md Index
internal/domain/AGENTS.md | Domain layer rules, data models, error types, zero-infra imports
internal/domain/id/AGENTS.md | Strongly typed entity IDs, code generation, type catalogue
internal/ports/AGENTS.md | Port interface catalogue (read internal/ports/*.go directly for contract)
internal/adapters/AGENTS.md | Adapter map, cross-adapter ban, storage/encryption/HTTP
internal/extproc/AGENTS.md | Standalone ExtProc service and its narrow shared-package exceptions
Local Source Routes
Use the root AGENTS.md for the constitution, ADR index, API contracts, and feature selection.
| Path | Purpose |
internal/app/builder.go | Broker construction order, shared services, and shutdown |
internal/app/handlers.go | Handler groups passed to routing |
internal/config/loader.go | Broker defaults, files, environment, and CLI flags |
internal/config/validator.go | Broker startup validation |
docs/configuration.md | Operator configuration contract |
examples/config/README.md | Feature configuration examples |
charts/agentic-identity-broker/ | Broker workload configuration |
docs/reference/token-exchange.md | Credential-free diagnostic attributes and classification |
tests/AGENTS.md | Integration and acceptance test routes |
Hexagonal Architecture Boundaries
Domain services depend on ports. Adapters implement ports. The app layer supplies their dependencies.
- Domain (
internal/domain/) — Business logic without infrastructure imports, except the OpenTelemetry API packages (coding-standards/OPENTELEMETRY.mdsection 1). Do not import adapters or app. - Ports (
internal/ports/) — Interfaces, minimal boundary data types, and configuration contracts. - Driven adapters (
internal/adapters/) — Port implementations. Import ports and domain. Do not couple independent adapter subsystems. - HTTP routing (
internal/adapters/http/routing/) — Receives handlers from app. It can use routing middleware and configuration. Do not create services or adapters there.
Read internal/adapters/AGENTS.md for existing subsystem factories and shared helpers.
Before you add a cross-layer dependency, read the port contracts and applicable ADR.
Package Map
Paths in this map are relative to internal/.
domain/
agents/ Agent lifecycle and canonical-ID resolution
approval/ Tool approval lifecycle, rate limiting, and sync
canonical/ Canonical identifier validation
cimdclient/ Outbound CIMD metadata, assertion signing, and key ownership
config/ Configuration domain types and validation
consent/ Agent delegation and grant management
encryption/ Encryption errors and branch-key subject types
id/ Strongly typed entity IDs
impersonation/ Local-mode delegated token issuance
jwe/ Encrypted token service
jwtauth/ JWT authentication and claim extraction
model/ Shared domain entities and value objects
jwtclaims/ JWT claim normalization for CEL
keylifecycle/ Shared key lifecycle with separate trust domains
oauth2/ OAuth2 authorization, CIMD, and JWKS publishing
oauth2server/ Broker OAuth2 authorization-server logic
oauth2session/ OAuth2 session lifecycle and token vault
permissionset/ Permission-set lifecycle and resolution
principal/ Principal context extraction
security/ Request security context and audit identity
server/ Server lifecycle configuration
storage/ Domain data models and endpoint discovery
thirdparty/ Third-party OAuth2 provider management
tokenexchange/ RFC 8693 token exchange and CEL evaluation
trustanchor/ Trust-anchor key-source resolution and local key-set validation
urivalidation/ Redirect and resource URI validation
ports/ Port contracts; read the `.go` files before editing
cel.go CELCompilerPort
cimd.go CIMD fetch and client-resolution contracts
cimd_client.go Outbound CIMD key, metadata, and assertion contracts
config.go ConfigPort and Config
encryption.go EncryptionPort and branch-key contracts
jwks.go JWKSPort and JWKSHealthPort
jwks_publisher.go JWKSPublisherPort and publisher health contracts
oauth2.go OAuth2Service
oauth2_mode_config.go Resolved proxy, local, and hybrid OAuth2 config
oauth2_token_proxy.go Upstream token request and response contracts
oauth2server.go Signing-key and credential contracts
server.go HealthState
storage.go Repository and transaction contracts
thirdparty_provider.go ThirdpartyOAuth2ProviderRepository
adapters/
outboundhttp/ SSRF-hardened CIMD HTTP fetcher and discovery client
encryption/
aws/ AWS KMS hierarchical keyring or base64 AES-256 mode
branchkey/ BranchKeyIdProvider implementation
noop/ Branch-key manager for the memory encryption backend
http/
enduser/ OAuth2 authorize, token, and metadata handlers
handlers/ SPA plus admin, approval, consent, and JWKS handlers
middleware/ Authentication, CORS, CSRF, and audit middleware
oauth2_sessions/ OAuth2 session management handlers
routing/ Route registration only
upstream/ Upstream OAuth2 proxy integration
jwks/ JWKS fetcher, published-JWKS, static (inline), and file key-set adapters
jwtauth/ JWT authenticator
storage/
factory.go Backend selection from configuration
memory/ In-memory storage
postgres/ PostgreSQL storage with sqlx and pgx v5
telemetry/ OpenTelemetry provider and slog handlers (context, principal policy, fan-out)
app/
builder.go Builder pattern — all DI wiring
handlers.go AdminHandlers + EnduserHandlers struct definitions
config/ Broker configuration adapter
telemetryhttp/ Credential-free outbound HTTP instrumentation
testutil/ Adapter-backed test helpers, not for domain tests
ptr/ Pointer helperBuilder Pattern (DI Wiring)
NewBuilder().With*().Build() in internal/app/builder.go validates inputs and initializes telemetry before these phases:
- Encryption — Create the required encryption adapter and branch-key manager.
- Domain services — Create services from port contracts.
- Handlers — Wire
AdminHandlersandEnduserHandlerswith the services.
Rules:
- Give routing pre-wired handler structs. Do not create services in routing.
- Add handlers to
internal/app/handlers.go. Create them ininternal/app/builder.go. Register their routes ininternal/adapters/http/routing/. - Make driven adapters depend on port interfaces, not concrete infrastructure. Give HTTP routing pre-wired handlers.
Handler Structs
AdminHandlers: Agents, Services, ProtectedResources, PermissionSets, ClientCredentials, SigningKeys, CIMDClientKeys.
EnduserHandlers: consent, session, OAuth2, JWKS, CIMD metadata, approval, and SPA handlers.
Routing Signatures
The contracts are in internal/adapters/http/routing/admin.go and internal/adapters/http/routing/enduser.go.
func SetupAdminRoutes(r chi.Router, h *app.AdminHandlers, cfg AdminRouteConfig)
func SetupEnduserRoutes(r chi.Router, h *app.EnduserHandlers, cfg EnduserRouteConfig)Logging
Read coding-standards/LOGGING.md before you add or change a log call. Use a *Context method, log principals as id.Principal, and never log credentials.
Tracing and Metrics
Read coding-standards/OPENTELEMETRY.md before you add or change a span or metric. Get tracers and meters from the OTel globals, set span kind and error status, set principals on spans only through id.Principal.SpanAttribute (add none until #356 provides it), and never put a principal in a metric attribute or a credential in any attribute.
Testing Conventions
- Use the root TDD requirements. Keep domain tests independent of infrastructure adapters.
- Put
_test.gofiles beside the package. Use the existing package convention. - Assertions: Use
testify. Userequirefor fatal preconditions. Useassertfor soft checks. - Subtests: Use
t.Run("description", ...). Use table-driven tests for validation and parameter sets. - For adapter mocks, use the existing
testify/mockhelpers and expectation checks. - For domain mocks, use the local port doubles. These use function fields or
testify/mock, depending on the package. - HTTP: Use
httptest.NewRecorder()andhttptest.NewRequest(). Use chi for URL parameters.
Key Storage Types
These are domain models, not database records. Paths in these reference tables are relative to internal/.
Keep adapter records in adapter packages.
| Type | Location | Key Fields |
Agent | domain/storage/ | ID, ClientID, DisplayName, Description, ServiceRequirements |
ThirdpartyOAuth2ProviderEntity | domain/model/ | ID, DisplayName, ClientID, Secret, Scopes, ProtectedResources |
UserGrant | domain/storage/ | ID, principal, agent ID, permission sets, validity |
UserSession | domain/storage/ | ID, principal, service ID, encrypted tokens, expiry |
Port Interfaces Quick Reference
| Port | Interface | File |
| Encryption | EncryptionPort | ports/encryption.go |
| Branch Key | BranchKeyManager (= BranchKeyRepository) | ports/encryption.go |
| Config | ConfigPort | ports/config.go |
| Storage | Repository and transaction interfaces | ports/storage.go |
| Provider Storage | ThirdpartyOAuth2ProviderRepository | ports/thirdparty_provider.go |
| JWKS | JWKSPort, JWKSHealthPort, JWKSPublisherPort | ports/jwks*.go |
| OAuth2 | OAuth2Service, OAuth2ModeConfig | ports/oauth2*.go |
| OAuth2 Server | Signing-key and credential contracts | ports/oauth2server.go |
| CEL | CELCompilerPort | ports/cel.go |
| Outbound CIMD | Key lifecycle, readiness, metadata, and assertion interfaces | ports/cimd_client.go |
| Upstream Token Proxy | OAuth2TokenProxy | ports/oauth2_token_proxy.go |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

