Threat model

AI coding agents are useful because they can read context, run tools, edit files, call APIs, and iterate quickly. Those same capabilities create a new local security boundary problem: the agent often sits close to source code, credentials, shell access, internal documentation, and production workflows.

Scope

This threat model covers local AI coding-agent workflows where an engineer uses an AI agent to inspect code, propose patches, run commands, call tools, read project files, or interact with development infrastructure.

In scope: source code, local file access, shell command execution, network egress, managed secrets, approval flows, audit logging, and prompt-injection risks involving untrusted project content.

Core risks

• Prompt injection through project content: untrusted README files, issues, docs, dependency files, generated output, or web content may contain instructions the agent treats as authority.
• Unbounded shell execution: an agent may run commands that delete files, modify git history, install packages, start listeners, or invoke tools with broader authority than intended.
• Credential exposure: an agent may read environment variables, config files, keychains, package tokens, or cloud credentials and include them in model context, logs, or network requests.
• Unauthorized network egress: an agent or tool may send source code, secrets, prompts, diffs, or local metadata to an unapproved domain.
• Audit gaps: agent actions may occur without a reliable record of what was read, written, executed, approved, denied, or sent over the network.

Control objectives

• Restrict file access to approved project roots.
• Deny network access by default unless allowed by policy.
• Redact or withhold managed secrets from model context.
• Require human approval for sensitive operations.
• Distinguish trusted instructions from untrusted content.
• Log agent actions with enough detail for investigation and compliance review.
• Fail closed when the runtime cannot enforce the required boundary.

Example policy surface

profile: engineering-default
roots:
  allow:
    - ./acme-checkout
filesystem:
  deny:
    - ~/.ssh
    - ~/.aws
    - .env
network:
  default: deny
  allow:
    - api.github.com
    - registry.npmjs.org
commands:
  require_approval:
    - "git push"
    - "terraform apply"
    - "kubectl *"
secrets:
  mode: brokered
audit:
  sink:
    - local
    - splunk

Limitations

Hauberk should not be presented as a replacement for endpoint security, secrets management, code review, least-privilege identity, CI/CD controls, vulnerability management, or secure software development practices.

Hauberk cannot fully protect secrets that are already committed to source code, pasted into prompts, displayed in command output, captured in screenshots, or stored in unmanaged local files outside policy enforcement.