Straight answers about protecting people and teams using AI.

CodeMarine is an independent protection layer for AI actions. CodeMarine Guard is for people using AI applications with files, accounts and connected tools. CodeMarine Dev is for software teams using coding agents, editors and pipelines.

Guard focuses on the actions AI applications take across a person’s computer, files and connected services. Dev adds code scanning, software supply-chain security, agent configuration checks and development-specific runtime policy.

Guard is for anyone giving AI applications access to real files, accounts or tools. Dev is for developers and security teams that use coding agents across a shared repository and delivery pipeline.

No. Frontier tools are strong semantic investigators and their native permissions still matter. CodeMarine adds continuous deterministic checks, cross-provider policy and independent evidence around them.

Yes. The continuous scanning and policy path is designed to work deterministically without a model call. Frontier reasoning is an optional investigation layer for ambiguous, novel or high-impact cases where semantic context adds value.

The same code revision, ruleset and policy should produce the same security decision. That gives CI gates, audit evidence, suppressions and regression controls a stable answer. A frontier model can still investigate the hard case, but it does not become the sole policy authority.

Native permissions and sandboxes are important. They are also scoped to one provider and one execution environment. Broad prompts can interrupt normal work, which encourages people to relax them. CodeMarine is designed to add a narrow independent layer around high-confidence risks while preserving one policy across providers.

The deterministic engine is intended to produce the same decision for the same revision, rules and policy. External intelligence, configuration changes or an optional model investigation can add new context, so the evidence records need to identify the revisions involved.

No. CodeMarine has a policy model for allow, warn and block decisions. A block is only meaningful where a supported enforcement path exists, so the product separates a policy verdict from proof that a particular host invoked and honoured it.

Only when the operation passes through a supported pre-execution path. Local shell hooks can cover some actions. Native APIs, hosted agents and remote tools need a governed gateway, scoped credentials or downstream policy. CodeMarine reports the gap instead of claiming universal interception.

It can evaluate supported shell actions before execution and return a policy decision for defined destructive classes. Coverage depends on the agent, host and installed adapter. Live canaries are planned to prove that the current host is invoking the guard.

A local command can be evaluated when it travels through a supported hook. Direct SDK calls, native connectors and provider-hosted tools need separate control points. The practical architecture combines CodeMarine policy with MCP or API gateways, scoped credentials, cloud policy and deployment controls.

It means CodeMarine receives the action before it happens and the host can honour the returned decision. Watching logs after execution is useful evidence but it is not prevention. CodeMarine keeps those two states separate.

Protection Center will separate adapter availability, local setup and live host proof. Until live proof ships, surfaces without current host evidence remain Setup needed or Planned.

It scans supported source and configuration files for known security risks, then applies structural confirmation and graph context where available. It watches the resulting workspace, so the same layer can evaluate changes from an agent, editor, automation or person.

Agents can introduce packages as easily as they introduce code. CodeMarine examines supported manifests, lockfiles, suspicious package names, known malicious packages, package sources and install-time behaviour so a new dependency does not become trusted merely because an agent suggested it.

CodeMarine has scanning paths for selected MCP configuration, skills, rules, prompts and persistent agent instructions. This extends the trust boundary beyond application source because the tools and instructions around an agent can change what it is able or encouraged to do.

No. Deterministic checks are strongest when the risky structure, package or policy condition can be described. Novel business-logic flaws and subtle multi-file vulnerabilities are where frontier investigation is valuable. CodeMarine’s role is to focus that investigation and turn verified discoveries into durable regression controls.

No. The continuous path is local-first and deterministic. Optional model investigation is reserved for cases that need semantic reasoning. This keeps routine protection predictable and token-efficient.

CodeMarine watches the shared workspace independently of the authoring tool. Provider-specific prevention still depends on the hooks and execution surfaces each tool exposes. That lets one policy cover the common result while the product reports differences in preventive coverage honestly.

A focused evidence packet can include the finding, relevant files, call paths, dependency provenance, policy and revision. The organization chooses the provider and sharing scope.

The original finding should disappear, deterministic checks should remain clean, protected files and dependency state should be reviewed and relevant tests should pass. The patch should also be bound to the expected revision so an approved fix cannot be silently applied to different code.

Routine deterministic scanning is local-first. Optional managed intelligence and frontier investigation can use approved external services. Before code leaves the workspace, the provider, shared scope and reason should be visible.

The action evidence model is designed to use classifications, fingerprints and reason codes instead of storing raw secret or command content. Any production integration should still be evaluated against the organization’s own logging, retention and privacy requirements.

Not yet. SSO, RBAC and compliance reporting are planned. Current work is focused on the protection engine, integrations and proof-backed coverage.

Current is available now. Beta works on defined paths but still has setup, host or proof limits. Planned is not available yet.