What is the difference between page-declared tools and server-declared tools for agent access?

Why This Matters for Security Teams

The distinction between page-declared and server-declared tools is not just an implementation preference. It changes what the agent can see, what state it can act on, and how quickly access decisions become stale. Page-declared tools stay coupled to the rendered interface and tend to reflect the same objects a user can inspect, which reduces mismatch. Server-declared tools introduce a second control plane that must be kept in sync, and that sync problem is where drift, overreach, and hidden privileges often start.

For agentic systems, the risk is amplified because tool access is part of the identity boundary. When an agent can read a page, infer context, and invoke actions through a separate backend integration, the gap between what is visible and what is executable widens. That is why current guidance from the OWASP Agentic AI Top 10 and NIST AI Risk Management Framework both emphasize runtime controls, scoped authority, and observable behaviour rather than static trust in the tool catalog. In NHI terms, the tool is not just functionality. It is an access path that must be governed like any other privileged workload.

In practice, many security teams discover tool drift only after an agent has already acted on stale context or reached beyond the page state that was originally approved.

How It Works in Practice

Page-declared tools are typically embedded into the same experience that presents the content to the human operator. That means the agent uses the page state, DOM, and visible context as one coherent workspace. For documentation, support workflows, and browsing tasks, this alignment is useful because the agent is less likely to operate against a shadow copy of the site. Server-declared tools, by contrast, are defined outside the page and must separately mirror the site through an integration layer, API, or orchestration service. That extra layer can be powerful, but it also creates a second source of truth.

The security question is less about where the tool is defined and more about how access is authorized at runtime. Best practice is evolving toward intent-aware checks, short-lived credentials, and workload identity so the agent proves what it is and what it is trying to do at the moment of use. That aligns with the direction of the OWASP Non-Human Identity Top 10 and the CSA MAESTRO agentic AI threat modeling framework, which both push teams toward explicit control of non-human actors.

A practical pattern is to combine:

• Page scope for read-only or documentation-oriented actions.
• Server-side policy checks for any write, delete, or external call.
• Ephemeral, per-task authorization instead of broad standing access.
• Telemetry that records the page context, tool invocation, and result together.

NHIMG’s research shows why this matters: the Ultimate Guide to NHIs reports that only 5.7% of organisations have full visibility into their service accounts, which is exactly the kind of blind spot that server-declared tools can hide behind if they are not tightly governed. These controls tend to break down when server-side integrations can execute actions that the visible page never exposed, because reviewers lose the ability to reconcile intent with authority.

Common Variations and Edge Cases

Tighter tool scoping often increases integration overhead, requiring organisations to balance developer convenience against auditability and blast-radius reduction. That tradeoff is especially visible in hybrid deployments where some tools must remain server-declared for performance, data residency, or legacy-system access. There is no universal standard for this yet, so guidance should be treated as current best practice rather than settled doctrine.

One common edge case is when the page is only a thin shell and the real business logic lives behind server APIs. In that environment, page-declared tools can look safer than they are if they merely proxy powerful backend actions. Another is when an agent chains multiple tools across pages and services. The page may appear benign, but the combined workflow can create privilege escalation, data exfiltration, or unintended side effects. That is why runtime policy evaluation matters more than the declared location of the tool alone.

Teams should also separate documentation use cases from transactional use cases. For content retrieval, page-declared tools usually fit best. For changes to records, tickets, or secrets, server-declared tools may be necessary, but they should be gated by workload identity, explicit approval thresholds, and short-lived credentials. Recent NHIMG case studies such as Replit AI Tool Database Deletion and Amazon Q AI Coding Agent Compromised show how quickly tool authority becomes a security issue when execution outpaces oversight.

Where pages are dynamic, highly personalized, or assembled from multiple sources, page-declared tools can also become unreliable because the rendered state changes faster than policy review or testing cycles.

Related resources from NHI Mgmt Group

• What is the difference between governing human access and governing AI agent access?
• What is the difference between managing human access and managing agent access?
• What is the difference between human access reviews and agent access reviews?
• What is the difference between access review and agent governance?