Identity & delegation
A cornerstone of the etg24 security model is explicit actor identity. Rather than issuing shared, monolithic API tokens, every automated process, external integration, and AI agent operates with its own distinct credential and identity.
Self-service credential management
API keys are generated self-service within the etg24 portal administration interface — no manual provisioning or support tickets required. When creating a key, you define its name, operational binding, and capability scopes.
The two dimensions of an API key
Every credential is characterized by two orthogonal properties:
1. Actor binding (on whose behalf does the key act?)
- User-bound: The agent acts on behalf of an individual team member (e.g. an AI assistant helping a property manager draft tenant communications). In audit trails, actions are attributed to that specific user’s agent. In MCP setups, user-bound keys connect to the Internal API endpoint (
https://api.etg24.de/api/internal/v1/mcp). - Tenant-bound: The agent acts on behalf of the company as an organization (e.g. background ERP synchronization, automated invoicing pipelines). Actions are attributed to the organization-level service. In MCP setups, tenant-bound keys connect to the Property Management API endpoint (
https://api.etg24.de/propertymanagement/v2/mcp).
2. Permission level (what is the key allowed to do?)
- Read-only: Can execute all permitted queries (
GET), but is blocked from executing any state-modifying command (POST). Ideal for reporting, monitoring dashboards, and search tools. - Read/write: Can execute permitted queries and authorized commands. Specific business capabilities and destructive actions (deletions) are gated separately.
| Dimension | Option A | Option B |
|---|---|---|
| Actor Binding | User-bound (specific employee) | Tenant-bound (organization-wide) |
| Permission Level | Read-only (Queries only) | Read/write (Queries + Commands) |
| MCP Target | .../api/internal/v1/mcp | .../propertymanagement/v2/mcp |
One key per agent
Integrations must not share credentials. Assigning an isolated key to each workload — a nightly database sync, a ticket classification bot, or a contractor’s script — provides critical operational guarantees:
- Isolated revocation: A malfunctioning or compromised agent can be revoked instantly without affecting any other integration or employee.
- Unambiguous auditability: Audit logs identify exactly which bot initiated a change, eliminating anonymous writes.
- Least privilege: Each credential holds only the minimal scopes required for its task.
Learn more about tracking agent actions in Audit trail & change attribution and managing key lifecycles in Key lifecycle.