Trust · Identity & access
Every call has an accountable identity.
Applications and agents authenticate with their own OAuth clients, belong to registered use cases and have named owners. IntSen is explicit about which identities it verifies and which your application reports.
Verified versus reported
What IntSen verifies
| Identity | Status | How |
|---|---|---|
| Application / agent client | Verified | From the OAuth token issued to the client; must be bound to the registration |
| Agent | Verified against registration | Recognized from the client; an agent id header must match an agent registered for that client |
| Use case (registration) | Checked | Named by header; must exist, be ready and be bound to the client |
| Task and conversation | Reported by your app | Used for grouping only; never for access decisions |
| End user | Reported by your app | Optional; stored only as a hash |
Ownership
- Each application service is a team's space in IntSen
- Each use case and agent lists named owners and a description of its purpose
- Owners receive budget, quality, compliance and usage alerts
- Team identity providers can be registered for a team's clients
Change control
- Resources are declared in YAML and applied through Git or the API
- Dry runs show validation errors and the diff before applying
- Use cases can require approval before they go live
- Changes keep their history; deletes are soft and restorable
Plan identity with your team.
We'll map your identity provider, clients and ownership model to IntSen in the pilot.