Beyond model guardrails, part 2: from credentials to consequences

Controlling identity, tools, authorization and agent actions

Part 1 established an important distinction: containing code execution is not the same as containing enterprise authority. We introduced the five agentic security control planes:

1. Governance and classification
2. Execution and network containment
3. Identity, credentials, tools and MCP
4. Authorization and action safety
5. Input trust, visibility, resilience and recovery

Part 1 covered governance and classification, and execution and network containment. This blog continues with identity, credentials, tools and MCP, and authorization and action safety.

Read part 1 of this blog series >>

An agent may be perfectly isolated from its host and still possess the ability to modify a cloud environment, query a private database, publish information or delete a remote resource through legitimate APIs.

That makes identity and authorization central to agentic security.

The objective is not simply to prevent an agent from "escaping" its runtime. It is to constrain what the enterprise will allow the agent to accomplish even when every request is technically valid, authenticated and delivered through an approved interface.

3. Identity, credentials, tools and MCP

Identity and credentials

Key takeaway: An agent should not automatically inherit the credentials of the application, developer workstation, CI environment or service account that launches it. Instead, each agent or workflow should use a distinct identity that can be audited, restricted and revoked independently.

Where an agent acts on behalf of a user, executing operations in that user's security context can prevent a generic service identity from gaining broader access than the initiating employee.

Long-lived secrets should remain outside the agent's direct execution environment whenever possible. A host service, credential broker, API gateway or tool proxy can hold the credential and attach it only after an individual request has passed authorization checks. This reduces the chance that the model, generated code or a compromised tool can read and exfiltrate the raw secret.

Temporary credentials reduce the time available for misuse, but expiration alone is not enough. A five-minute token with administrative access across an entire cloud account remains dangerously powerful.

Credentials should therefore be restricted across three dimensions:

time, resources and permitted operations.

For managed Mac devices, Jamf Pro's Local Administrator Password Solution (LAPS) reduces reliance on shared or static administrator passwords by generating unique credentials per device and supporting controlled retrieval, auditing and automatic rotation.

For agent-to-service access, mechanisms such as AWS Security Token Service and HashiCorp Vault dynamic secrets address a complementary requirement: issuing temporary, appropriately scoped credentials rather than exposing long-lived secrets to agent runtimes.

For an agent, this might mean receiving a credential valid only for the current task, limited to one repository or database, and restricted to the exact operations required.

Identity and credential controls

Separate agent identities

• Available implementation options: dedicated service principals, workload identities or delegated user context
• When customers should use it: every agent accessing private enterprise resources
• Why it matters: supports attribution, least privilege, revocation and per-agent policy

Credential brokering

• Available implementation options: API gateway, host-side proxy, secrets broker or tool gateway
• When customers should use it: agents calling cloud, SaaS, repository, database or security APIs
• Why it matters: keeps long-lived secrets outside the agent's execution environment

Short-lived credentials

• Available implementation options: AWS STS sessions, workload identity federation, Vault leases or short-lived OAuth tokens
• When customers should use it: tool-using production agents
• Why it matters: limits the time available for stolen-token abuse

Task-scoped permissions

• Available implementation options: resource-specific and operation-specific credentials
• When customers should use it: agents performing narrowly defined workflows
• Why it matters: prevents unrelated resources and operations from becoming available

User-context execution

• Available implementation options: perform operations under the initiating user's permissions
• When customers should use it: enterprise copilots and employee-facing workflow agents
• Why it matters: prevents a shared agent identity from bypassing user access controls

Immediate revocation

• Available implementation options: disable identity, terminate sessions, remove role bindings or block the broker
• When customers should use it: every production agent
• Why it matters: enables rapid containment during an incident

Tools

Key takeaway: Tools should expose capabilities, not environments.

An agent's tools define much of its operational attack surface:

• A generic shell can potentially read files, modify configuration, install software, initiate network connections, invoke cloud command-line tools and execute arbitrary programs.
• An unrestricted SQL interface may read, alter, or delete any object permitted by the connected account.
• A generic HTTP client may reach internal services, cloud metadata endpoints or attacker-controlled destinations.

Where possible, broad interfaces should be replaced with narrow, parameterized operations. For example:

• An agent that needs repository status may receive a get_repository_status tool rather than a raw shell.
• An agent that drafts customer responses may receive create_response_draft but not send_message.
• An infrastructure agent may be allowed to generate a deployment plan without receiving direct access to delete or rebuild an environment.

Each tool should have a strict input schema, validated parameters, explicit resource scope, separated read and write operations, and a clearly defined security owner.

Tool and MCP controls

Parameterized tools

• Available implementations options: narrow APIs such as read_ticket, create_draft or propose_patch
• When customers should use it: every tool-using agent
• What it prevents: arbitrary command composition and unnecessary operations

Read/write separation

• Available implementations options: separate retrieval tools from modification and deletion tools
• When customers should use it: repositories, databases, CRM and infrastructure
• What it prevents: read workflows unexpectedly becoming destructive

Schema and parameter validation

• Available implementations options: type checks, resource allowlists, path validation and operation constraints
• When customers should use it: every tool invocation
• What it prevents: malformed, manipulated, or over-broad requests

Approved tool registry

• Available implementations options: reviewed and versioned list of allowed tools and integrations
• When customers should use it: enterprise agent platforms
• What it prevents: unreviewed tools being dynamically introduced

MCP server approval

• Available implementations options: security review, owner assignment, version tracking and access restrictions
• When customers should use it: organizations using MCP servers
• What it prevents: malicious, compromised or over-privileged MCP integrations

Tool-definition integrity

• Available implementations options: detect changes to tool names, descriptions, schemas and instructions
• When customers should use it: MCP and dynamic tool environments
• What it prevents: tool poisoning and misleading descriptions

Per-call MCP authorization

• Available implementations options: route every invocation through policy and credential controls
• When customers should use it: MCP servers with enterprise access
• What it prevents: treating model tool selection as authorization

Token audience validation

• Available implementations options: validate that tokens were issued for the receiving MCP server
• When customers should use it: authenticated MCP deployments
• What it prevents: token passthrough and confused-deputy attacks

MCP servers

Key takeaway: MCP servers are part of the trusted computing base and should be governed like so.

An MCP server may expose local filesystem access, databases, developer tools, SaaS applications, browser automation, cloud APIs or command execution.
Connecting to an MCP server is therefore not equivalent to installing a passive data connector. It can introduce executable functionality and new authority into the agent environment.

An approved MCP server should be governed like any other privileged enterprise integration. Its code, publisher, deployment location, tool definitions, credential model, downstream access and updates all become part of the agent system's trusted computing base.

Organizations should:

• Maintain an approved MCP registry
• Identify an owner for every server
• Review its implementation and tool definitions
• Record which agents may connect to it
• Monitor changes to its capabilities.

The official MCP security guidance identifies token passthrough as an anti-pattern and requires appropriate token validation, including ensuring that credentials are intended for the receiving service.

Tool selection remains subject to downstream authorization.

4. Authorization and action safety

Authorization

Key takeaway: The most important control in an agentic architecture is a deterministic enforcement layer outside the model.

Instead of allowing a model to decide whether or not an action is allowed, this enforcement layer makes the determination:

1. The model can produce a proposed tool call containing an operation, target, and parameters.
2. A policy enforcement point then evaluates the authenticated identity, initiating user, session, requested action, resource, data classification, environment and current risk conditions before allowing or rejecting the operation.
3. Policy systems such as Open Policy Agent (OPA) can separate policy decisions from application logic.
4. OPA acts as a policy decision point, while the API gateway, tool broker or receiving service remains responsible for applying the result.

A Cedar-based service such as Amazon Verified Permissions can similarly evaluate authorization policies and return an allow or deny decision. The application or gateway must still enforce that decision.

This separation is necessary because the model cannot securely enforce its own permission boundary. The same model deciding what to do may have been influenced by a malicious document, poisoned repository, compromised tool response, incorrect context or mistaken interpretation of the user's request.

Authorization should validate the exact parameters, not only the general tool name:

• Permission to use a database tool does not imply permission to delete every database.
• Permission to access a repository does not imply permission to publish its contents.
• Permission to send an email does not imply permission to send any attachment to any recipient.

The receiving system should decide whether that specific agent, acting for that specific user and task, may perform that specific operation on that specific resource.

Authorization controls

Deterministic policy evaluation

• Available implementation options: OPA, Cedar-based systems, application rules or cloud IAM conditions
• When customers should use it: sensitive tool calls
• Why it matters: keeps authorization outside probabilistic model reasoning

Complete mediation

• Available implementation options: re-evaluate each request at the receiving system
• When customers should use it: reads, writes and administrative operations
• Why it matters: prevents earlier approval from becoming blanket access

Resource-level authorization

• Available implementation options: validate repository, record, account, database or environment
• When customers should use it: agents with access to multiple resources
• Why it matters: prevents cross-resource privilege misuse

Parameter-level authorization

• Available implementation options: validate recipients, paths, quantities, targets and operation types
• When customers should use it: high-impact or externally visible actions
• Why it matters: prevents an allowed tool from being used dangerously

Purpose and session binding

• Available implementation options: bind authorization to the current task and initiating user
• When customers should use it: delegated and multi-step workflows
• Why it matters: prevents authority from being reused outside its intended purpose

Agent self-protection rules

• Available implementation options: block writes to approval policy, logging, credentials, MCP configuration and security settings
• When customers should use it: coding and infrastructure agents
• Why it matters: prevents agents from weakening their own controls

Action safety

Key takeaway: Human approval should protect meaningful boundaries

Some operations should not execute immediately even when the agent has a valid identity and a policy engine determines that the operation is technically permitted.
Examples include:

• Production deletion
• Infrastructure replacement
• Financial transactions
• Credential or permission changes
• External publication
• Sensitive customer communication
• Active security testing

Approval must occur through a trusted interface outside the agent's control. The approver should see the:

• Agent identity
• Initiating user
• Requested operation
• Target resource
• Exact parameters
• Expected effect
• Reason for the action

A vague message such as "The agent wants to continue" is not sufficient.

The agent must not be able to change the approval interface, approve its own request, conceal parameters or convert a timeout into automatic approval.

When approval is not received, the default outcome should be rejection.

At the same time, requiring a human click before every low-risk tool invocation can create approval fatigue. There is a useful middle ground between unrestricted autonomy and approval for every individual action: bounded delegated authority.

Here’s an example of what that looks like:

1. An operator might authorize an agent to perform up to three deployments to a specific staging environment during the next 30 minutes, using only an approved deployment tool and without permission to modify IAM, networking, databases or production resources.
2. The approval grants a defined envelope of authority rather than a general exemption from future controls.
3. That envelope can be limited by identity, resource, operation, duration, number of actions, cost, environment or other policy attributes. Critically, those bounds must be enforced by the policy, credential, and tool layers themselves; they should not exist only in an approval ticket or prompt.
4. Where possible, the approved envelope should be translated into a constrained session or credential before tool access is granted, so the agent receives only the resources, operations, duration, action count or spending authority that was approved.
5. Downstream policy enforcement should then continue to validate each request against the same envelope.

This provides two layers of control:

Before execution, issue only constrained authority; during execution, continue to enforce that authority on each request.

This mirrors established IAM principles. AWS session policies, for example, can further restrict the effective permissions of a temporary role session rather than expanding the underlying role's authority.

Action-safety controls

Trusted human approval

• Available implementation options: out-of-band workflow displaying the explicit operation and parameters
• When customers should use it: destructive, irreversible, legally significant or production-facing actions
• Why it matters: model errors and prompt injection becoming immediate enterprise actions

Step-up authentication

• Available implementation options: MFA or stronger reauthentication for critical approval
• When customers should use it: credential changes, finance, production administration and high-risk testing
• Why it matters: compromised sessions approving sensitive operations

Bounded delegated authority

• Available implementation options: session-scoped authorization defining resources, operations, duration, action count or spending
• When customers should use it: controlled repetitive workflows
• Why it matters: provides autonomy without turning one approval into unlimited authority

Staged outputs

• Available implementation options: draft, branch, pull request, proposed plan or pending update
• When customers should use it: code, infrastructure, configuration and communications
• Why it matters: direct model output becoming an immediate change

Automated validation

• Available implementation options: tests, policy checks, security scanning and schema validation
• When customers should use it: staged outputs
• Why it matters: unsafe or malformed proposals reaching production

Rate limits

• Available implementation options: limits per agent, user, session, tool and resource
• When customers should use it: autonomous and multi-agent workflows
• Why it matters: machine-speed abuse and runaway loops

Execution budgets

• Available implementation options: maximum actions, duration, cost, writes or retries
• When customers should use it: long-running autonomous tasks
• Why it matters: unbounded resource consumption

Circuit breakers

• Available implementation options: suspend the agent or tool when thresholds are exceeded
• When customers should use it: production agents
• Why it matters: continued operation after anomalous behavior

Administrative kill switch

• Available implementation options: revoke credentials, block tools, isolate networking or stop workloads
• When customers should use it: privileged production agents
• Why it matters: delayed containment during an incident

Stage outputs before they become actions.

Staging and sandboxing protect different boundaries: A sandbox constrains runtime execution. Staging creates a workflow boundary between something the agent proposes and something the enterprise actually changes.

For example:

• A coding agent can create a branch or pull request instead of committing directly to a protected branch.
• An infrastructure agent can generate a proposed plan instead of applying it.
• A customer-service agent can create a draft rather than send it.
• A security agent can prepare a test procedure in an isolated environment rather than immediately target a live system.

Staged outputs create an opportunity for deterministic validation, automated testing, security scanning, policy enforcement and human review.

GitHub describes related principles in the security architecture for GitHub Agentic Workflows. Agents are treated as untrusted, execution is isolated, service access is mediated, and output is constrained rather than without unrestricted modification. The agent may still produce an unsafe proposal, but the proposal does not become an enterprise action until it crosses a separately controlled boundary.

Agents should also be prevented from modifying the controls that govern their own execution. Approval settings, policy files, workflow definitions, security hooks, MCP configurations, logging components, credential-broker rules and network controls should remain outside the agent's writable scope unless a separate reviewed process authorizes the change.

Part 2 conclusion: authority must be deliberately granted

An agent's security is not determined only by whether it is isolated, but by the combination of identity, credentials, tools, downstream authorization and the degree of autonomy the enterprise chooses to grant.

A useful design principle emerges:

Do not give the agent authority and then ask it to remember the limits. Encode the limits into the identity, credential, policy and tool layers that surround it.

But even strong authorization cannot prevent every mistake or manipulation.

Part 3 examines the remaining problem: how to handle untrusted context, observe agent behavior, contain multi-agent delegation, recover from failure and decide which control stack different classes of agents actually require.