Assessing Agent Security: Start with One Tool Call

Author: Max Luo · October 11, 2026 · Teloa AI Security

An enterprise agent can fail through a sequence of individually plausible actions. A model treats text in a retrieved ticket as an instruction. A tool trusts the user identifier supplied in its arguments. A connector performs the operation using a shared credential with access to the entire customer database. Each component appears to work; their composition creates an unauthorized access path.

This article develops a reproducible assessment around one task: retrieve this month's customer tickets, create a summary, and send it to the project team. The question is how identity, authority, data, and external effects propagate through that workflow, and which component can stop them. The designs and assessment records are illustrative; they are not findings about Teloa's compliance.

The Enterprise Agent Identity and Authorization Security Baseline v1.0 organizes the underlying design experience into 240 requirements. This article turns those requirements into engineering questions. Normative wording, levels, and applicability remain defined by the standard.

1. Specify the business intent and attacker capabilities

Assume user-42 can access tickets in tenant-a / project-a. The task permits October tickets and a summary without raw customer contact information. Sending requires confirmation of the actual recipients and content. The agent exposes ticket search and message drafting; its execution instance is run-17.

Consider three distinct attacker capabilities: controlling a ticket's body, submitting messages through an exposed channel, or controlling a code process inside the execution instance. These represent prompt injection, identity impersonation, and execution compromise. For this review, the enterprise IdP, platform registry, policy service, and egress gateway remain trusted. Compromise of those control-plane components requires a separate infrastructure and incident-response assessment.

These paths prevent an assessment from becoming a test of whether the model refuses malicious wording. Enforcement should reject a dangerous invocation even if the model proposes it. A model that happens not to propose the invocation does not demonstrate that the execution boundary works.

2. Place Harness controls on the correct trust boundary

An agent combines a model and a Harness. The Harness manages its loop, context, tools, and orchestration. Frameworks provide development abstractions; runtimes provide durable execution and recovery. The existence of a tool callback says little about whether it is unavoidable, receives trustworthy identity, or constrains arbitrary code execution.

Draw two paths. The decision path carries verified identity into the policy service. The access path carries an operation from the execution environment through the gateway to a downstream system. They must meet on the same verified invocation. Model output, tool returns, web content, and execution instances are treated as untrusted; platform-controlled components that the agent cannot modify enforce authorization.

“All requests pass through our tool function” needs further investigation. Can code, browsers, MCP processes, or database drivers access the network independently? Does a security hook run inside the same writable process as the script it checks? Can the sandbox read real SaaS credentials? If those paths bypass the gateway, approval on the controlled tool covers only part of the system.

V4.2.2 and V4.2.3 require default-deny outbound networking and rejection of direct access for platform-hosted environments. Endpoint deployments are assessed under V5.4. A gateway cannot merely forward TLS traffic: it must understand operations, resource scopes, and credential destinations to enforce authorization.

3. Build a verifiable invocation record

The following record is assembled by the platform from authentication, registration, and tool parsing. Its fields are illustrative, not a new protocol. The model proposes a tool and arguments; it does not generate trusted identity attributes.

{
  "request_id": "req-17-02",
  "principal": {
    "user": "user-42",
    "agent": "agent-support",
    "workload": "run-17",
    "tenant": "tenant-a"
  },
  "task": "task-october-summary",
  "tool": "tickets.search",
  "tool_version": "sha256:reviewed-schema-digest",
  "arguments": {
    "project": "project-a",
    "period": "2026-10",
    "limit": 100
  },
  "context": {
    "has_untrusted_input": true,
    "has_nonpublic_data": true
  },
  "authorization": {
    "policy_version": "policy-23",
    "decision_id": "decision-221"
  }
}

Three details matter. The tenant comes from trusted registration, not the request body. The tool version identifies a reviewed definition; a same-named tool with changed parameters must not silently inherit an old approval. Context state is maintained by the platform; the model cannot reset it by claiming that the input has been cleaned.

The untrusted-input flag is only a minimal illustration. Production systems also need provenance, data labels, and propagation rules. Sensitive data does not become public merely because it is summarized, written to a file, stored in memory, or passed to another agent. Records must omit raw credentials and protect sensitive ticket and recipient information through redaction or restricted access.

4. Check six invariants along the request path

An invariant must hold regardless of the model's next proposed action.

1. Identity is not self-reported. Derive the user and agent from authenticated workload identity and platform registration. Changing an argument named user_id must not change the principal. See V1.4.3.
2. Authority only narrows. Operations must fit the user's current rights, agent scope, and applicable task and delegation limits. A child agent cannot supply privileges the initiator lacks. See V2.2 and V2.4.
3. Approved content matches the actual effect. A change to recipients, content, attachments, resource scope, or quantity invalidates the old approval. See V3.4.2 and V3.4.3.
4. Credentials remain bound to their destination. Controlled components obtain real secrets and inject them only into the bound host and path. See V4.1 and V4.7.
5. Reading does not authorize sending. After untrusted input or nonpublic data is consumed, outbound disclosure requires approval by default. See V6.2.1 and V7.5.4.
6. Visibility follows recipient permissions. A channel member allowed to initiate a task may not disclose its result to every other member. Query authorization and display authorization are separate decisions. See V7.1.

These are engineering interpretations across multiple requirements. Level distinctions still matter: the intersection of user and agent permissions is L1; recomputing effective permissions on every invocation is L2. The whole reference workflow must not be described as a mandatory L1 implementation.

5. Use a successful request to assign control ownership

Observe a permitted workflow before modifying it into denial experiments.

Evidence must correlate across components. A Harness log saying “denied” is insufficient: check that the gateway did not obtain credentials, the downstream system produced no message, and queued retries did not execute. Conversely, a successful downstream log does not identify who authorized the effect. Join request, decision, approval, and downstream effect IDs to reconstruct the path from decision to outcome.

6. Denial experiments reveal more than feature lists

Use isolated tenants and test downstream systems. Define an observable effect counter, such as messages received by a test mailbox or writes to a test ticket, and retain a timeline for each request.

If the model does not produce an attack request, a test-only entry point can submit the equivalent tool invocation to exercise enforcement independently. That entry point must not become a production bypass. Record model behavior separately from execution enforcement so that evidence for one is not mistaken for evidence for the other.

7. Turn experiments into assessment results and remediation

Version 1.0 has 90 L1 requirements, 227 cumulatively at L2, and 240 at L3. Select a target level, then assess applicability. V2.3 applies to scheduled or long-running tasks. Exclude it only when neither form of offline user delegation is supported. A deployment without scheduling may still have long-running tasks that continue after the user leaves; that does not make the section inapplicable. Supporting either capability without pre-run permission checks is a gap.

The following is a hypothetical assessment example, not a product evaluation.

Partial satisfaction does not establish compliance with a requirement. Section 6.4 requires every clause to be satisfied. Capability-oriented wording checks what the enterprise can enable; other requirements check controls actually enabled and effective in the assessed deployment. A completion ratio helps prioritize work, but cannot replace evidence or establish certification.

Use the assessment tool to record status, evidence, owner, and target date. Archive the platform version, target level, and scope with the export. After a fix, rerun the original experiment and verify that denied paths have zero external effects. For revocation and emergency stop, record measured delay against the agreed limit instead of simply claiming “instant revocation supported.”

8. Start with paths that can cause material loss

Choose one valuable workflow: customer-data export, external messaging, production changes, or payments. First establish trusted principals, authorization on actual parameters, controlled credential egress, and correlated audit evidence. Then extend the review to child agents, scheduled tasks, MCP, and browser actions. Every new execution entry point must satisfy the same relevant invariants.

A useful design principle is to let the model propose candidate actions while trusted controls decide their execution conditions. Bind approval to the object that will create the external effect, and check it where that effect is dispatched. This constrains the consequences of prompt injection and gives security teams deterministic denial experiments for evaluating the boundary.

Continue with identity binding, issuance, and revocation, then permission computation and execution enforcement. Teloa AI Security maintains the standard and tool source; the architectures are available in the multilingual gallery. Derived from Teloa development practice, the baseline is open for other platforms' design and assessment.