AI agent controls for private development networks

September 24, 2026 - 5 minute read

AI agent controls must hold when a task is ambiguous, a tool returns unexpected output, or the model proposes the wrong action. In a private network, the systems within reach can include sensitive repositories and operational services. Internet isolation does not remove the need to limit that access.

Factory's Agent Safety & Controls combines deterministic controls with Droid Shield secret scanning. Use those mechanisms alongside infrastructure permissions and existing source-control review requirements. Each should have a defined purpose and a test that demonstrates it.

AI agent controls start with the execution identity

Define what the task needs before choosing credentials. A development change may require reading a repository, installing approved dependencies, running tests, and proposing a branch. It usually does not require a standing credential for the production environment.

Droid operates on the machine where it runs and uses the configured tools and services. The host account, filesystem permissions, repository token, and network access all affect the possible consequences of a command. Review that combined authority rather than only the agent's visible settings.

Use a disposable environment for the initial policy test. Give it a working copy and scoped access to the services required for validation. Keep unrelated home directories, cloud credentials, and production secrets outside the permitted filesystem.

Source-control permissions should preserve the team's review process. A token capable of bypassing branch protections creates a different risk from one that can only prepare a branch and pull request. Confirm the effective permissions with the repository administrator.

Write the identity decision into the deployment record. When the same workflow later moves from a laptop to a CI runner, repeat the review. A new execution identity can expand access even when the task and model remain unchanged.

Distinguish approval from prohibition

Factory provides separate command allow, deny, and block lists. Allowlisted commands can run without additional approval. Denylisted commands require explicit confirmation. Blocklisted commands have no approval path.

Use the blocklist for organization-mandated prohibitions and the denylist for actions that a reviewer may legitimately authorize. Confusing these two makes the policy weaker or more restrictive than intended.

Command rules are one layer. A permitted build tool can still execute project-defined scripts, and a script can interact with the filesystem or network. Bound those effects through sandbox and infrastructure controls rather than assuming the name of the entry-point command describes everything it can do.

Test a harmless representative command for each policy decision. Confirm the expected automatic execution, approval prompt, or rejection. Include the actual invocation forms the workflow uses and preserve the results with the policy version.

Keep the rules understandable for operators. When work is blocked, the person responding should know whether the next step is approval, a narrower task, or an administrator-reviewed policy change. Routine frustration should not become a reason to replace a precise policy with broad permissions.

AI agent controls need filesystem and network limits

Factory's sandbox supports filesystem and network restrictions. Its configuration can limit reads and writes and constrain command-level egress. These controls provide a concrete boundary around the environment where a proposed action runs.

Start with the task's working directory and required tools. Deny access to unrelated credential locations and host configuration. Decide whether the workflow needs command-scoped isolation or a whole-process sandbox, and validate that choice in the target environment.

Network rules should describe the necessary destinations. A private deployment may need an internal model service, Git server, package mirror, and collector. It does not automatically need access to every service on the corporate network.

Factory's deployment patterns recommends combining the runtime with existing proxies, certificate authorities, containers, and VMs. Keep those infrastructure controls in place when increasing autonomy. An approval setting should not silently change the network architecture.

Observe a complete task and test a prohibited path using a safe test destination. Record which layer rejected the action. That evidence helps distinguish a working policy from a model that simply did not attempt the prohibited operation during the demonstration.

Distribute hard policy through managed settings

Factory's Enterprise Controls reference separates hard controls from session defaults. Organization policy establishes boundaries, while users select local preferences within them. A preferred model or autonomy setting is different from an enforced ceiling.

Use organization-managed settings for the restrictions that must apply consistently. Review model and MCP policy, command restrictions, sandbox configuration, and managed hooks as a coherent deployment policy.

For offline or managed fleets, system-managed settings provide an organization policy source on the machine. Verify that the file is present and valid on the execution account before accepting the installation. A distribution job reporting success is weaker evidence than an observed policy test.

Maintain a promotion process for policy changes. Test in a non-sensitive environment, record the expected behavior, and expand deliberately. A stricter command rule can break validation, while a relaxed endpoint rule can change the data boundary.

Make the exception process explicit. Record who may approve a new model route, tool server, or network destination and what evidence they need. Prefer a narrowly scoped change with an owner over a temporary broad exception that nobody later removes.

Use hooks and secret scanning for specific jobs

Factory hooks run at defined events in the agent lifecycle. A PreToolUse hook can inspect an intended action and return a permission decision. Managed hooks can connect the workflow to organization-specific checks or approved internal services.

Treat hook code as a security-sensitive dependency. Review its permissions, failure behavior, and any destination that receives data. A hook used for data-loss prevention can itself transmit sensitive context if its endpoint is outside the approved boundary.

Droid Shield scans staged diffs before Git commit and push operations and blocks likely secrets. Factory documents fail-closed behavior when a diff is too large to scan safely. Keep that protection scoped correctly in the operating explanation.

Staged-diff scanning does not establish that every prompt, tool result, or telemetry record has been scrubbed. Likewise, a prompt instruction to avoid secrets does not replace file permissions. Combine these mechanisms according to the data path each actually governs.

Test the organization's custom checks using synthetic values and disposable changes. Confirm the rejection and recovery path without introducing real credentials into the test. Operators need a safe way to investigate false positives while preserving the mandatory control.

Verify controls alongside the delivered change

A useful acceptance run produces both a reviewable change and evidence that the policy held. Choose a task with known validation, then include safe negative tests for prohibited access and actions.

Factory's compliance and audit guidance describes complementary evidence from customer telemetry, supported cloud audit events, and workflow logs. Use source-control and CI records to establish the diff, validation result, and reviewer approval.

For a private-network pilot, capture the execution identity, active policy version, approved model endpoint, and test results. Avoid storing sensitive interaction content merely to make the evidence package look complete. Collect what the review actually requires.

Recheck controls after moving the workflow, changing credentials, or adding an integration. A policy that held on a developer machine may interact differently with a runner's permissions or proxy configuration.

Factory Private lets an organization place the control plane in its own infrastructure. The deployment becomes governable when the organization can also explain what Droids may access, which actions require review, and which boundaries remain enforced regardless of model behavior.