The problem
Scripts, integrations, and customer-owned agents need non-human access without sharing personal credentials or trusting identity supplied inside model-generated tool arguments.
What EKOS does
Administrators create a service account, assign role context, issue tokens whose cleartext is shown once, and revoke individual tokens or deactivate the account when access should end.
- Tenant-bound non-human identities
- One-time token display with hash-only storage
- Expiration, revocation, and account deactivation
- REST and authenticated MCP access
- Transport-derived identity with audited use
How it works
An administrator creates a tenant-bound service account, assigns its role context, and issues one or more tokens with recorded expirations.
The cleartext token is displayed exactly once; EKOS stores only its hash.
The same bearer credential authenticates the REST API and the authenticated streamable-HTTP MCP transport.
MCP identity is established on the connection before a tool runs; a tenant assertion inside a tool argument cannot override it, and a mismatch is recorded for audit.
Individual tokens can be revoked at any time, and deactivating the account invalidates all of them at once.
Business outcome
Organizations can embed governed EKOS knowledge into existing workflows and assistants while retaining tenant context, revocation, provenance, and audit behavior.
Proof and human control
EKOS stores token hashes, derives tenant and role context from the authenticated transport, and audits supported REST and MCP activity against the machine identity.
Example in practice
A customer issues a dedicated 90-day token to an internal assistant. The assistant can request cited policy answers, while its authenticated tenant context cannot be replaced by a different tenant identifier in a tool call.
Scope today
Service accounts provide authenticated tenant and role context across supported REST and MCP surfaces. Authorization behavior is specific to each supported surface.