Agent Permissions & Security Boundaries

A Heicode Agent may read code, modify files, run commands, access the network, call MCP tools, or connect to external services. Whether these actions are allowed should be decided jointly by workspace permissions, the execution environment, and user approval.

Permission Types

Least-Privilege Principle

Grant the Agent only the permissions the current task truly needs:

• A read-only task should not be granted write permission;
• A local-code task should not allow access to directories outside the project by default;
• A test task that doesn't need the network should have the network turned off;
• A task that doesn't need production data should not have production credentials injected;
• A task that doesn't need to release should not have push, merge, or deploy permissions.

Command Approval

Before approving a command, check at least its scope, target path, whether it includes delete or overwrite operations, whether it will install unknown software, whether it will access external networks, and whether it will read or print environment variables.

Be extra cautious with commands like:

rm -rf
sudo
curl ... | sh
git reset --hard
git clean -fd
chmod -R
kubectl delete
terraform destroy

This doesn't mean these commands can never be used — it means you must confirm the target, blast radius, and recovery plan.

Skip-Permissions Mode

Skipping permissions can reduce manual confirmation, but it significantly expands what the Agent can do. Use it only temporarily, and only when all of the following hold:

• You're using an isolated workspace or a disposable Sandbox;
• No production credentials or sensitive data are involved;
• Git state is recoverable;
• Network access is controlled;
• There are resource and cost limits;
• You turn the mode off immediately after the task ends.

It's not advisable to leave it on long-term in a personal home directory, a production server, a shared dev machine, or an environment holding long-lived cloud credentials.

Secrets & Sensitive Data

• Don't write API keys, SSH private keys, or database passwords directly into the task description;
• Use environment variables or a controlled secret-injection mechanism;
• Logs and error reports should be masked by default;
• When credentials appear in Agent output, revoke and rotate them immediately;
• Third-party models and MCP servers may have their own data-handling policies; assess each separately.

MCP Trust Boundary

An MCP Server is not inherently trustworthy. Before enabling one, confirm its origin, maintenance status, permission scope, authentication method, network targets, and returned content. An MCP with file, network, or credential permissions can be as powerful in practice as a local plugin.

Multi-Agent Scenarios

In an Agent Swarm, make the following boundaries explicit:

• Whether the Agents share the same workspace;
• Whether they share environment variables and secrets;
• When one Agent's changes become visible to other Agents;
• Whether the Team Lead can approve high-risk actions;
• Who merges conflicting changes;
• Whether a failed Agent's workspace and logs are kept.

User Responsibility

Heicode can provide approval, isolation, logging, and rollback, but it cannot replace the user's final judgment over code, commands, credentials, and release actions. Before entering production, you should still perform independent code review, testing, and release approval.