Architecture and operating model
When an AI agent calls a tool, model output is not an authorization decision. Validate identity, token audience, scope, tenant, resource ownership and action parameters at the tool layer. For remote MCP, the server acts as an OAuth resource server and validates access tokens. For a local stdio server, the boundary is the launching user and the operating-system permissions granted to the process.
A tool description signals intent to the model but is not a security control. Separate read, write, delete and external-communication actions into distinct tools or scopes, and prefer resource- and action-level permission over a broad admin grant. Indirect prompt injection makes untrusted document content influence a tool call; model approval is unreliable until data provenance is separated from instruction provenance.
For high-impact actions, separate plan and execution: the agent drafts a change, a policy engine validates parameters, a human approves when required and an idempotency key enforces one execution. Audit should join user, agent version, tool, parameter summary, policy decision, approval and result identifiers without logging secrets or raw sensitive content.
- 1User intent and data provenance
- 2Structured tool proposal from model
- 3Server identity, scope and parameter policy
- 4Approval, idempotent execution and audit
Design parameters
- Identity and audience
- Verify that the token targets this MCP server and binds the correct tenant and user.
- Scope separation
- Split read, create, update, delete and external-send permissions.
- Parameter policy
- Enforce resource, recipient, amount, time range and data class on the server.
- Approval and replay
- Use human approval, expiring decisions and idempotency for high-impact actions.
Worked example
If a support agent reads 40,000 tickets monthly but may send only 50 replies daily, separate `tickets.read` and `tickets.reply`. The send tool enforces tenant, ticket ownership, recipient domain and 50/day on the server. A prompt saying `send to every customer` cannot bypass scope or quota.
A policy may score risk as probability × impact: a low-impact read at 0.1×2=0.2 can be automatic, while a transfer at 0.2×10=2.0 requires human approval. These are business-policy examples, not model confidence or an absolute security guarantee; calibrate them with false positives and negatives.
Example commands: replace lab values and confirm permissions and software versions before use.
assert token.aud == MCP_RESOURCE
assert token.tenant_id == resource.tenant_id
require_scope('tickets.reply')
assert request.ticket_id in authorized_ticket_ids(user)
assert recipient_domain in tenant.allowed_domains
assert daily_count(user, 'reply') < 50
result = execute_once(idempotency_key, request)
audit(user_id, agent_version, tool_version, policy_decision, result.id)Troubleshooting
| Observation | Likely cause / distinction | Verification |
|---|---|---|
| Agent selects an unexpected tool | Descriptions may overlap, untrusted content may act as instructions or permissions may be broad. | Trace prompt/data provenance, tool version and policy decision through one audit ID. |
| 401/403 affects only some users | Audience, scope, tenant or ownership may differ. | Without logging token values, compare issuer, audience, scope and policy reason code. |
| The same action occurs twice | Retries may not bind to an idempotency key. | Join client request ID, server idempotency key and result record. |
Acceptance checks
- Classify data access and side effects for every tool.
- Test read, write, delete and send scopes independently.
- Reject wrong-audience and cross-tenant tokens.
- Run indirect prompt-injection tests with an untrusted document.
- Test approval expiry and idempotency for high-impact actions.
- Verify audit joins identity, policy and result while masking secrets.
Related concepts
Authentication and sessions
Authentication proves who a user or workload is; authorization determines what that identity may do. Successful sign-in does not grant access to every resource. User sessions, service identities, API tokens and device certificates have different lifecycles. Design session duration, token renewal, employee departure, lost-device handling and emergency access alongside initial sign-in. Measure which existing sessions remain usable and which new access attempts are denied when the identity provider becomes unavailable.
Least privilege and separation of duties
Least privilege limits the permissions needed for a task to specific resources and time periods. Giving everyone the same administrator role complicates access reviews and investigations. Separate daily-use identities from privileged accounts, and restrict interactive use and unnecessary network access for service identities. An access matrix should show which operation an identity may perform on each resource. Test whether an application keeps working after a permission is removed: unnecessary privileges sometimes become visible only during controlled reduction.
Trust boundary and failure domain
A trust boundary separates components governed by different access decisions; a failure domain groups resources that one event can affect together. Two VLANs do not create a strong trust boundary when routing between them is unrestricted. Backups in different folders still share a failure domain if one administrator can delete both. Assess physical location, identity provider, management account, network path and power source separately. Test which access paths and recovery options remain available when a component is lost.
File permissions and service identities
File access combines users/groups, permission bits, ACLs and security policies. Running an application as root can hide permission problems; prefer a justified, restricted service identity in production. Directory traversal permission differs from file-read permission. Sharing permissions do not necessarily override filesystem restrictions. Identify the account actually running the application, directory chain and ACLs when troubleshooting. Test narrowly required access rather than opening permissions globally.
Telemetry and time correlation
Telemetry combines logs, metrics and events that explain system behavior. A log describes an event, a metric shows behavior over time, and a distributed trace follows a request across components. Clock differences can make one event appear to occur at several times. Use synchronized clocks, reliable source identifiers and consistent time-zone handling. Alarm design should consider duration and user impact alongside thresholds. Monitor gaps in collection separately: absence of logs must not be interpreted as absence of incidents.
Policy lifecycle
A policy needs management as its scope changes, not just when it is enabled. Separate drafting, observation, pilot deployment, enforcement and periodic review. Every exception needs an owner, reason, scope and expiry date. A successful pilot can still cause production false positives if test data does not represent real user behavior. Identify affected users and applications before deploying with measurable acceptance criteria. A rollback path should identify who may reverse the change and under which conditions, rather than merely locating an interface button.
Primary documentation
Prepared by the Doz Teknoloji technical team using the primary references below. Calculations and lab scenarios state their assumptions; validate the applicable product version before rollout.