Security Model

Agent-ready does not mean uncontrolled. An MCP-first system describes every capability in a machine-readable way, and simultaneously defines who may call it, under what conditions, and what traces are created. Security is not a retroactive add-on, but part of the capability design.

Six authorization levels

Authentication answers: Who are you? Authorization answers: What are you allowed to do? An MCP-first system needs both questions, and answers them on six independent levels that together determine the effective access.

Level 1: User Role

The role of the logged-in user forms the broadest level. It determines fundamental access classes, not individual tools.

admin
manager
employee
viewer
external_client

Level 2: Tenant Scope

In multi-tenant systems, every access must be tenant-bound. No agent may read or write across tenants, even if its user role would technically allow it.

tenant:abc
project:123
contact:456

Level 3: Tool Scope

Every tool is secured with its own scopes. An agent receives exclusively the scopes that are necessary for its defined task.

contacts:read
contacts:write
projects:read
projects:write
files:read
files:write
emails:draft
emails:send
calendar:create
billing:read
billing:write
admin:users
admin:security

Level 4: Resource Scope

Beyond tool scopes, access can be restricted to individual resource types. This ensures that an agent with contacts:read still cannot view every contact resource.

resource.project.visible
resource.contact.visible
resource.employee.visible
resource.file.downloadable
resource.email.readable

Level 5: Risk Level

Every tool carries a declared risk level. This level feeds into the confirmation policy and the audit configuration.

Level 6: Confirmation Policy

The confirmation policy defines which additional hurdle must be cleared before execution. It is configured per tool and enforced by the policy layer, not by the agent itself.

no_confirmation_required
confirmation_required
step_up_auth_required
admin_approval_required
four_eyes_required
not_allowed_for_ai

Tool visibility

Whether a tool exists is already security-relevant information. An agent that knows a forbidden tool can use it as an attack surface, even if the subsequent call would be blocked.

A sales assistant receives, for example, the following filtered tool list:

Human-in-the-loop

MCP-first does not mean fully automatic. It means fully controllable, but controlled. For sensitive or risky actions, the system interrupts the agent and actively obtains the user’s consent.

The agent recognizes from the declared risk metadata that an action requires human approval, and hands over control. Only after explicit confirmation is the tool executed.

The following example shows a typical approval dialog for bulk sending external emails, one of the most common critical agent actions:

Step-up Authentication

For particularly sensitive actions, an active session is not sufficient. Even a logged-in administrator must re-confirm their identity before critical operations are executed.

Typical triggers for step-up auth:

• Changing or assigning admin privileges
• Changing payment data or subscription
• Salary data or payroll exports
• Generating or rotating API keys
• Full data exports
• Deleting users or tenants

Accepted step-up methods (depending on system policy):

Password re-entry
TOTP / Authenticator app
Passkey
Admin approval by second person
Four-eyes principle

Consent Ledger

Every consent to an agent action is an event that should be permanently stored. The consent ledger makes it possible to trace in retrospect which action was approved by whom, for which scope, and with which security method.

Stored fields of a consent entry:

consentId, unique ID of the consent
userId, approving user
agentId, acting agent
clientId, connected MCP client
toolName, called tool
inputSummary, structured summary of inputs (not plaintext)
riskLevel, declared risk level of the tool
approvedAt, timestamp of approval
expiresAt, validity of the approval (if time-limited)
approvalMethod, approval method used (e.g. "totp", "passkey", "manual")

Some approvals can be valid for a limited time, for example, a one-time approval for a specific send. Others apply for a session or a configured time period. The policy determines the granularity.

Audit Trail

Every MCP action creates an audit entry. This entry is immutable, tenant-bound, and machine-evaluable. It forms the basis for compliance evidence, anomaly detection, and internal reviews.

{
  "event": "mcp.tool.executed",
  "tool": "emails.send_external",
  "tenantId": "tenant_123",
  "userId": "user_456",
  "agentId": "agent_sales_assistant",
  "clientId": "client_claude_desktop",
  "riskLevel": "critical",
  "confirmationId": "confirm_789",
  "inputHash": "sha256:a3f2c1...",
  "result": "success",
  "createdAt": "2026-06-11T10:00:00Z"
}

The audit log can be monitored automatically for anomalies: unusual execution frequencies, actions outside normal working hours, or access to scopes that an agent does not normally use, all of this is detectable because every action is cleanly typed and audited.