Securing the Seams: Why Siloed Identity Platforms Can't Stop Agent Over-Privilege

Date: 06 November 2026

Executive Summary

AI agents create a security problem at the seams between identity systems, model runtimes, orchestration layers, APIs, and enterprise tools. Each platform may authenticate users correctly, yet the combined workflow can still give an agent more authority than the user, application, or task requires.

The business risk is unauthorized data access, destructive tool use, weak accountability, and policy violations that are difficult to reconstruct after the fact. The security decision is clear: treat agent authorization as a separate control plane. Do not assume that existing workforce identity, cloud IAM, or application permissions automatically govern an agent's complete tool-call chain.

Contents

1. Architecture and Threat Model
2. Authentication, Authorization, Enforcement, and Audit
3. Where Siloed Controls Break
4. Implementation Controls
5. Risks and Mitigations
6. Deployment Checklist
7. Frequently Asked Questions

Architecture and Threat Model

An agentic workflow usually contains several identities and trust boundaries:

• A human identity that starts or approves a task.
• An agent runtime that interprets instructions and chooses actions.
• A workload identity used by the runtime to access services.
• A tool identity or API credential used to call a specific system.
• Data identities and tenant boundaries inside the target systems.

These identities are related, but they are not interchangeable. A user may be authorized to read a customer record in a CRM. The agent runtime may have a broad service account that can read every customer record. The CRM may correctly accept the service account token. The result is still over-privilege because the final authorization decision has lost the user's purpose, task scope, and constraints.

The relevant threat model includes malicious prompts, untrusted retrieved content, compromised agent sessions, tool impersonation, stolen credentials, excessive service permissions, and accidental instruction leakage. It also includes ordinary software failure. An agent can select the wrong tool, pass the wrong identifier, repeat a request, or interpret a natural-language instruction too broadly without any attacker controlling the model.

The key trust boundary is the transition from model output to external effect. Text generated by a model is not an authorization decision. A tool call becomes security-sensitive when it can read regulated data, modify business records, send communications, move money, change infrastructure, or create durable access.

A Typical Tool-Call Flow

Consider a user asking an agent to update a supplier record. A simplified flow looks like this:

1. The user authenticates to the agent application.
2. The application creates an agent session and attaches task context.
3. The model proposes a tool call such as update_supplier.
4. The orchestration layer resolves a credential or token for the target API.
5. The policy layer evaluates the subject, action, resource, purpose, and context.
6. The tool gateway validates the request and calls the external system.
7. The gateway records the decision, request, response, and correlation identifier.

In a siloed design, steps 1, 4, and 6 may be controlled by different identity platforms. The workforce provider knows the user. The cloud provider knows the workload. The SaaS application knows the API token. None may know enough about the complete chain to determine whether this particular update is allowed.

That gap creates a confused-deputy condition. The agent becomes a deputy with more authority than the initiating user or task. It may use a broadly scoped credential because the target system cannot accept delegated context, or because the integration was designed for reliability rather than least privilege.

Four Controls That Must Stay Distinct

Authentication

Authentication answers: Who or what is presenting credentials? It may establish a user, workload, service, or agent-session identity. Strong authentication does not determine what the identity may do after it is recognized.

Authorization

Authorization answers: Is this subject allowed to perform this action on this resource under this context? For agents, context should include the initiating user, task identifier, tool, requested operation, data classification, tenant, and approval state where applicable.

Policy Enforcement

Policy enforcement is the mechanism that prevents an unapproved action from reaching the target system. A policy decision stored in a log is not enforcement. The enforcement point must sit on the path of the tool call, ideally before credentials are released or the request is sent.

Auditability

Auditability answers: What happened, under whose authority, using which policy, and with what result? A provider's access log may show that a service account called an API. That is not enough to explain which human initiated the task, what the model proposed, what policy allowed it, or whether the request was transformed before execution.

Implementation Controls

Use an Agent-Specific Authorization Context

Propagate a signed or otherwise integrity-protected authorization context through the workflow. It should bind the user, agent session, task, tool, action, resource, and expiration. Do not trust model-generated fields as authoritative. The orchestrator or policy service must derive and validate them.

Illustrative request context:

{
  "subject": "user:1842",
  "agent_session": "sess_7f91",
  "task": "supplier_update",
  "tool": "erp.update_supplier",
  "action": "write",
  "resource": "supplier:3921",
  "purpose": "correct banking address",
  "expires_at": "2026-11-06T15:30:00Z",
  "approval": "required"
}

Separate Planning from Execution

Let the model propose an action, but require a deterministic component to validate it. The validator should check tool name, argument schema, resource ownership, data classification, rate limits, and approval requirements. High-impact operations should use step-up approval or a two-person workflow rather than silent execution.

Illustrative policy pseudocode:

allow(request):
    require request.session_is_active
    require request.expires_at > now()
    require request.user_can_access(request.resource)
    require request.tool in request.task.allowed_tools
    require request.action in request.task.allowed_actions
    deny if request.data_classification == "restricted"
         and not request.approval.valid
    allow only if request.arguments.match_schema

Reduce Credential Reach

Prefer short-lived, audience-restricted credentials over static keys. Bind credentials to the target service and operation where the platform supports it. Keep tool credentials behind a gateway so the model runtime does not receive raw secrets. A gateway can also remove unsupported fields, enforce tenant boundaries, and reject calls that exceed the task scope.

Make Tool Contracts Explicit

Each tool should declare its permitted operations, resource types, side effects, required approvals, data returned, and failure behavior. A read-only search tool should not silently expose an administrative endpoint. A delete operation should not be represented as a generic “manage record” capability.

Illustrative tool contract:

{
  "name": "erp.update_supplier",
  "operations": ["write"],
  "resources": ["supplier"],
  "side_effect": true,
  "approval": "finance_owner",
  "returns": ["supplier_id", "updated_fields"],
  "max_fields": 4
}

Design for Observability

Use one correlation identifier across the user request, model response, policy decision, credential exchange, gateway request, and target-system response. Record policy version, decision reason, subject, resource, tool, arguments after appropriate redaction, and outcome. Store enough information to investigate without copying sensitive data into every log.

Monitoring should detect unusual tool sequences, repeated denials, access outside a user's normal tenant, sudden changes in tool selection, and attempts to bypass approval. These signals support response, but they do not replace preventive enforcement.

Risks and Mitigations

Risk	Why Siloed Identity Fails	Mitigation
Service-account overreach	The target API sees a broad workload identity instead of task context.	Use short-lived, scoped credentials and an agent-aware policy gateway.
Prompt injection	Untrusted content changes the model's proposed action.	Treat retrieved content as data, validate every tool call, and restrict tools by task.
Privilege laundering	A low-privilege user causes a high-privilege agent to act.	Compute effective authority as the intersection of user, task, agent, and tool permissions.
Approval bypass	Approval exists in a workflow system but is not enforced at execution time.	Require an approval token or decision reference at the tool gateway.
Inadequate investigation	Logs identify an API key but not the human, prompt, policy, or model decision.	Propagate correlation IDs and record the complete authorization chain.
Unsafe retries	Transient failures cause duplicate writes or repeated side effects.	Use idempotency keys, bounded retries, and explicit side-effect classification.

Deployment Checklist

• Map every human, workload, agent-session, tool, and target-system identity.
• Document each trust boundary and the data that crosses it.
• Define task-level allowed tools, actions, resources, and expiration times.
• Place a policy enforcement point before every consequential tool call.
• Keep raw credentials out of model prompts and model-visible context.
• Validate tool arguments against strict schemas.
• Require explicit approval for destructive, financial, external-communication, and access-management actions.
• Use correlation IDs across the full request chain.
• Test prompt injection, confused-deputy behavior, replay, credential theft, and retry failures.
• Review denied calls and policy exceptions as operational security signals.

Frequently Asked Questions

Can existing IAM solve agent over-privilege?

IAM remains necessary, but it may not carry task intent, model-session context, or tool-specific constraints. Add an agent authorization layer where those decisions are made.

Should every tool call require human approval?

No. Approval adds latency and operational cost. Use risk-based controls, with automatic execution for bounded low-impact actions and stronger approval for durable or high-impact effects.

Is a read-only agent always safe?

No. Read access can expose sensitive data, cross tenant boundaries, or provide information that enables later attacks. Read operations still need resource and data-classification controls.

Should the model decide whether a call is permitted?

No. The model can propose an action, but a deterministic policy enforcement point should make the authorization decision.

What should be logged?

Log the initiating subject, session, task, tool, action, resource, policy version, decision, approval state, correlation ID, and outcome. Redact or tokenize sensitive arguments.

How do we handle third-party tools?

Place third-party integrations behind a controlled gateway, define explicit contracts, restrict outbound destinations, and require independent validation of returned data before it influences another tool call.

What is the first control to implement?

Start with a complete tool inventory and a gateway that can deny calls. Visibility without an enforcement point will not prevent over-privilege.

Make Agent Authority Explicit

AI-agent security fails when identity is treated as a single field rather than a chain of authority. The practical answer is to connect user identity, task scope, tool permissions, policy decisions, and audit records before an external effect occurs.

Use AXEC for governed AI-agent security, and schedule a 30-minute meeting at https://cal.id/axec/demo?duration=30.