Agent authority: what changes when identity and tools are in scope?

TL;DR: The core security problem is not escape from runtime but preventing an agent from turning technically valid requests into unauthorised business action, according to Jamf. Jamf argues that agentic security must move beyond containment of code execution to constraining enterprise authority, with distinct identities, scoped credentials, governed MCP servers and deterministic authorization outside the model.

Editorial analysis by NHI Mgmt Group, based on content published by Jamf: “Beyond model guardrails, part 2: from credentials to consequences”.

Key questions

Q: How should security teams govern agentic systems that access sensitive data?

A: Start with declared policy for what data is sensitive, which identities may access it, and what conditions make the access acceptable.

Q: Why do agentic systems require a separate authorization layer?

A: Because a model cannot safely enforce its own permission boundary.

Q: What do security teams get wrong about MCP and tool governance?

A: They often review each integration in isolation and miss the combined permission path.

Practitioner guidance

• Define a unique agent identity per workflow Stop letting an agent inherit the launcher’s credentials.
• Broker secrets outside the agent runtime Keep long-lived secrets in a host-side proxy, broker or gateway and attach them only after the request has passed policy checks.
• Approve MCP servers as privileged integrations Maintain an approved registry, assign an owner for every server, review tool definitions and record which agents may connect.

Bottom line: Agentic security fails when teams focus only on containing execution and ignore the authority the agent can still exercise through valid tools and credentials.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →