Security Boundaries in Agent Architecture

Recently, many coding agents have evolved to read the file system, execute shell commands, and generate code directly. However, most teams run these components within a single security context, exposing them to serious security threats.

The biggest risk is prompt injection. If an attacker hides a malicious prompt in a log file or similar location, the agent may generate and execute a script to exfiltrate sensitive information such as ~/.ssh or ~/.aws/credentials in order to carry out that prompt. This means the privileges held by the agent can spread across the entire infrastructure.

To build a secure system, it is necessary to distinguish the four core components that make up an agent system and define the trust level of each.

• Agent: An LLM-based runtime that can be vulnerable to prompt injection.
• Agent Secrets: Sensitive information required for system operation, such as API tokens and DB credentials.
• Generated Programs: Code generated by the agent, which is unpredictable and can be the riskiest element with the most powerful privileges.
• Filesystem/Environment: The physical or virtual environment in which the system runs.

To strengthen security, the Agent Harness should be designed so that it does not expose secrets directly to the agent. The agent should perform functions only through scoped tools with strictly limited privileges, and if generated programs require separate credentials, these should be managed in an independent security context.