AI agents rarely operate in isolation. They call tools, execute under service identities, load runtime components, and delegate work across other agents and services. Each of these relationships extends the system's effective security boundary.

In previous rooms, you examined how excessive tool access, over-privileged identities, and untrusted runtime components can expand an agent's attack surface. TryTrainMe is now preparing its agent estate for wider deployment, so your role on the security team shifts from identifying exposure to enforcing and validating safer execution boundaries.

Earlier, the key question was: What could the agent reach?

Now it becomes: What should the agent still be able to reach after hardening?

A security control is useful only if it changes system behaviour in a way that can be verified. In production environments, this evidence may come from platform telemetry such as OpenTelemetry or agent-level tracing platforms such as Langfuse. In this room, the same principle is represented through TryTrainMe's event logs and Security Validation Console.

You will harden the TryTrainMe estate by first building an inventory of its components, then reducing tool scope and identity privileges, validating the integrity of runtime components, containing unsafe capabilities, and finally confirming through evidence that the applied controls are being enforced.

The goal is not to introduce another isolated security mechanism, but to bring together the controls explored throughout the previous rooms into a defensible execution boundary that limits what agents can do and provides evidence that those limits are actually enforced.

Learning Objectives

• Build a component inventory covering agents, tools, identities, and runtime-loaded components.
• Apply security controls across tool scope, identity privilege, and component integrity.
• Distinguish standing privilege from just-in-time access in an agent workflow.
• Verify runtime component integrity before an agent loads it.
• Contain an unsafe execution path by disabling the affected capability, revoking associated authority, and preventing an unsafe runtime component from loading again.
• Use event-log evidence to confirm that a hardening control was actually enforced.

Prerequisites

• ASI02: Tool Misuse & Exploitation
• ASI03: Agent Identity & Privilege Abuse
• ASI04: Agentic Supply Chain Compromise