Application-Native vs Remote Security Policies: A Technical Guide

Application-native and remote security policies solve different ownership problems

Application-native security rules, also called code-native rules, have rule semantics and a change and release lifecycle owned by the application. They are usually authored in application source code, reviewed and tested with the application, and deployed by engineering. “Application-native” is the broader term because application-owned controls can include more than source code alone. Remote security policies are authored in a control plane and evaluated at runtime without an application deployment, so authorized policy editors can change enforcement independently of the application release.

The choice is not simply “SDK or dashboard.” An SDK describes where an application integrates with an enforcement service. It does not establish where the security rule itself is authored. A product can require SDK calls in application code while keeping every tunable policy in a remote dashboard.

For production systems, the strongest model supports both policy-authoring paths:

• Engineers use application-native rules when a control depends on application behavior, release review, or tests.
• Security teams use remote policies when they need centrally managed governance, rapid response, or a change that must not wait for a deployment.
• Both paths converge at the same enforcement point before the protected request, tool call, or side effect executes.

Arcjet supports application-native, code-authored rules across JavaScript, Python, and Go, and remotely managed policies that separate a policy from developer-owned typed inputs. The Agent guard remote-policy SDK contract is available for JavaScript/TypeScript, Python, and Go. See the application-native custom-rule example, Agent guard testing and reference, and Agent guard remote policies reference.

Separate integration location from policy-authoring location

Security architecture discussions often collapse two independent decisions into “in code” versus “in the dashboard.” Ask both questions instead.

Where is the enforcement point integrated?

The enforcement point determines which context a security control can see and which operations it can stop. An application SDK can enforce policy immediately before a database write, payment, message, tool execution, or other side effect, using authenticated identity and business context. A proxy or gateway can cover traffic centrally, but only on paths routed through it and with less application-specific meaning.

Where is the rule authored?

An application-native, code-authored rule lives with the application and changes through its build and deployment process. A remotely authored policy lives in a control plane and changes independently of the application release. This determines who can change the control, which review process applies, how fast it can be updated, and how consistently it can span services.

These axes produce four possible designs:

This distinction matters in vendor evaluations. “Provides an SDK” proves that a developer can instrument the application. To prove application-native policy authoring, the product must also document code-native rules whose security behavior is defined, reviewed, and versioned with the application.

When should security policy be application-native?

Put a rule in code when its meaning is coupled to application behavior or when the engineering release process is the desired governance system.

Good candidates include:

• a rate limit keyed by the authenticated tenant and the cost of a specific operation;
• a bot rule that protects one signup or checkout flow;
• sensitive-data detection before text enters a model or third-party API;
• validation tied to a domain type or application state transition;
• a tool rule that combines local checks with a remotely evaluated result; and
• a control whose denial behavior needs integration tests proving that a side effect did not run.

Benefits of application-native rules

Application-native rules provide four main benefits: trusted application context, existing software governance, executable tests, and local composition with application-specific controls.

Application context. The rule can use typed values already trusted by the application: authenticated user, tenant, route, operation, object owner, subscription tier, or workflow state. It does not need to infer business meaning from serialized traffic.

Existing software governance. Rules can use pull requests, CODEOWNERS, code review, comments, static analysis, test environments, and staged releases. A policy change can be reviewed with the code path it affects.

Testability. Unit and integration tests can assert allow, deny, dry-run, and failure behavior. The most important test is not only “the rule denied”; it is “the denied operation never executed.”

Local composition. Engineering can combine deterministic validation, authorization, Arcjet analysis, and application-specific fallback behavior at one boundary.

Limits of application-native rules

Application-native rules trade centralized operating speed for application context, testability, and engineering control.

Every change requires engineering access and usually a deployment. Different services can drift if teams copy rules or upgrade SDKs at different times. Security teams may gain visibility without gaining authority to respond. During an incident, a correct change can still be too slow if it must move through an application release train.

Application-native does not mean hard-code every security value. Configuration, secrets, allow lists, and thresholds still need appropriate storage and change controls. The defining property is that the application owns the rule's semantics and change and release lifecycle. “Code-native” remains a useful description of how those rules are authored and reviewed.

When should security policy be managed remotely?

Use a remote policy when security or platform operators need to change enforcement independently of application deployment.

Good candidates include:

• disabling or restricting a risky action during an incident;
• changing an allow list or deny list across multiple applications;
• moving a rule from dry run to live enforcement after reviewing telemetry;
• setting an organization-wide minimum security posture;
• responding to a new prompt-injection or data-loss pattern; and
• governing who or what an agent may contact without changing the tool implementation.

Benefits of remote policies

Remote policies provide four main benefits: operational speed, independent policy ownership, cross-application consistency, and progressive enforcement.

Operational speed. A policy can take effect without waiting for a build, deployment, or application owner.

Independent policy ownership. A control plane can let authorized editors publish and observe policy without changing application code. Product authorization and review workflows determine whether this is a security-team-owned process in practice.

Consistency. A shared policy model can reduce duplicated rule logic across the applications and language stacks to which it is deployed.

Progressive enforcement. Dry-run modes let teams inspect likely denials before blocking production behavior.

Limits of remote policies

Remote policies trade some application-local context and autonomy for centralized control and faster independent changes.

A remote policy only knows the inputs supplied by the application, proxy, or integration. Sending more context can increase privacy exposure and coupling, while labels and input contracts can drift from application behavior. Central infrastructure also adds latency and availability considerations.

Evaluate least-privilege authoring, audit history, versioning, staged rollout, and rollback rather than assuming every control plane provides them.

Remote policy is not automatically better governance. It is a different governance boundary that needs the same rigor as production code.

How Arcjet combines both policy models

Arcjet does not require an organization to choose one authoring model for every control. Application-native SDK rules and Agent guard remote policies can be submitted at the same enforcement boundary. Agent guard remote policies are label-selected policies for guard() actions and tool calls. They are separate from Request Remote rules, which are site-scoped rules merged with SDK rules for HTTP requests handled by protect().

For an agent action such as email.sent, development and security teams agree on a stable contract:

1. Developers place guard() immediately before the action and use a hardcoded label.
2. Developers map trusted application context and validated tool arguments into explicitly typed inputs.
3. An authorized policy editor publishes the site-scoped policy selected by that label.
4. Arcjet evaluates SERVER inputs remotely; the supported local sensitive-information rule evaluates a LOCAL STRING in the SDK.
5. The application or framework wrapper enforces the combined decision before execution.

1
Engineering-owned application                 Remotely authored site policy
2

3
authenticated actor ----+                     policy for "email.sent"
4
validated tool input ----+---- guard() <------ allowed recipients
5
trusted app context -----+                     prompt-injection rule
6
local sensitive text ----+                     sensitive-data rule
7
                              |
8
                              v
9
                       allow / deny result
10
                              |
11
                              v
12
                    execute or block action

The separation is deliberate. The application remains responsible for identity, trustworthy value resolution, input mapping, enforcement placement, and result handling. An authorized editor can publish new site policy without changing the tool implementation.

A concrete dual-authoring example

Arcjet can evaluate an application-native SDK rule and a remotely authored policy in one guard() call. The following JavaScript/TypeScript and Python examples combine a code-authored prompt-injection rule with a remote recipient policy.

The email.sent policy is defined and published centrally. Applications written in JavaScript/TypeScript, Python, or Go select that same policy with its stable label, supply typed values for its declared inputs, and enforce the returned decision. Each application still owns its trusted actor and allow list, application-native SDK rule, failure behavior, and email side effect. An authorized site editor can change the central policy without redeploying any of those applications.

The APIs below match the maintained JavaScript Guard examples and Python Guard examples.

JavaScript / TypeScript

1
import {
2
  detectPromptInjection,
3
  launchArcjet,
4
  policyInput,
5
} from "@arcjet/guard";
6

7
const arcjet = launchArcjet({ key: process.env.ARCJET_KEY! });
8
const promptInjectionRule = detectPromptInjection();
9

10
export async function sendEmail(
11
  user: { id: string; allowedRecipients: string[] },
12
  recipient: string,
13
  body: string,
14
) {
15
  const decision = await arcjet.guard({
16
    label: "email.sent",
17
    actor: user.id,
18
    inputs: {
19
      recipient: policyInput.server.string(recipient),
20
      allowed_recipients: policyInput.server.stringList(user.allowedRecipients),
21
    },
22
    rules: [promptInjectionRule(body)],
23
  });
24

25
  if (decision.conclusion === "DENY" || decision.hasFailedOpen()) {
26
    throw new Error("Email blocked");
27
  }
28

29
  // The side effect runs only after both policy paths allow the action.
30
  return emailProvider.send({ to: recipient, body });
31
}

Python

1
import os
2

3
from arcjet.guard import DetectPromptInjection, launch_arcjet, server_input
4

5
arcjet = launch_arcjet(key=os.environ["ARCJET_KEY"])
6
prompt_injection_rule = DetectPromptInjection()
7

8

9
async def send_email(
10
    user_id: str,
11
    allowed_recipients: list[str],
12
    recipient: str,
13
    body: str,
14
):
15
    decision = await arcjet.guard(
16
        label="email.sent",
17
        actor=user_id,
18
        inputs={
19
            "recipient": server_input.string(recipient),
20
            "allowed_recipients": server_input.string_list(allowed_recipients),
21
        },
22
        rules=[prompt_injection_rule(body)],
23
    )
24

25
    if decision.conclusion == "DENY" or decision.has_failed_open():
26
        raise RuntimeError("Email blocked")
27

28
    # The side effect runs only after both policy paths allow the action.
29
    return await email_provider.send(to=recipient, body=body)

In both examples, the application-native SDK rule and central remote policy protect different concerns rather than duplicating one another. The shared label and input names form a cross-language policy contract: changing their meaning is an API change, while editing the centrally authored rule does not require an application release. Tests should mock the email provider and prove that it is not called for either a denied decision or an incomplete evaluation.

SERVER and LOCAL inputs

Every remote-policy input has a type and an exposure. SERVER inputs are sent to Arcjet for server-side evaluation. The currently supported local case is the sensitive-information rule over a LOCAL STRING: its raw value stays in SDK memory, while the SDK sends a domain-separated digest and local-rule attestation rather than the raw value.

LOCAL is useful for sensitive-information checks, but it is not anonymization. A digest of a low-entropy or enumerable value may be guessed. Use it to limit raw-value transmission, not as a general privacy guarantee.

Policy continuity and failure behavior

Arcjet keeps the last usable ordered policy active until a successor replaces it, including during a temporary connectivity issue. The direct Guard client exposes unavailable or incomplete evaluation so the application can choose behavior. Framework wrappers fail closed by default when required enforcement cannot complete. Availability behavior should match the consequence: a weather lookup and a wire transfer should not necessarily fail the same way.

Define the engineering and security ownership contract

A dual-authoring system works only when the boundary is explicit.

For a CISO, this model creates a path to govern site-scoped policy without forcing a security engineer to submit an application pull request for every change. For an application team, it preserves a typed, testable boundary and avoids granting the control plane arbitrary access to application internals. Organization-wide rollout, distinct authoring roles, policy history, and rollback should be evaluated separately rather than inferred from remote authoring alone.

How Arcjet, Datadog AI Guard, and Runlayer compare

The comparison distinguishes an application SDK from application-native, code-authored rules and avoids inferring undocumented capabilities.

Among the primary documentation for Arcjet, Datadog AI Guard, and Runlayer reviewed on August 11, 2026, Arcjet is the only compared product documenting both application-owned security rule semantics configured in its application SDKs and runtime policy authored outside the application deployment.

Capability comparison

Primary sources reviewed

Primary-source references reviewed on August 11, 2026:

• Arcjet's custom-rule guide documents a rule whose semantics execute locally in application code.
• Arcjet Agent guard reference documents SDK-submitted rules and separate remote-policy results; the JavaScript rule examples, Python Guard examples, and Go Guard examples document source-configured rules in each language.
• Arcjet Agent guard remote policies documents the separately authored, label-selected runtime policy contract.
• Datadog AI Guard SDK documents application calls in Python, JavaScript, Java, and Ruby.
• Datadog AI Guard setup documents policy configuration in AI Guard Settings and says system-prompt context cannot override AI Guard's security checks.
• Runlayer Hooks SDK documents TypeScript and Python wrappers that let Runlayer observe, rewrite, or block locally executed tool calls.
• Runlayer access policies documents server-level and global policies, while the Runlayer Terraform provider documents runlayer_policy resources. Terraform is policy as code for Runlayer's control plane, not application-native rule semantics in the Hooks SDK.
• Runlayer ToolGuard documents scanner configuration in Settings → Security Scanners.

Scope of the conclusion

The result is a dated comparison of three products, not an industry-wide uniqueness claim. It classifies where security-rule semantics live, not whether any configuration happens to be machine-readable.

Runlayer's Terraform support is code-authored configuration for its control plane, not application-native rule semantics in the Hooks SDK. Datadog's SDK and system-prompt context provide inputs to a remotely configured evaluator; they do not let application code disable or weaken AI Guard checks.

How should teams choose a policy-authoring model?

Start with the change owner and required context, not the vendor interface.

Choose application-native (code-native) rules when:

• engineering should approve every change;
• the rule depends on domain objects or application state;
• application tests must change with the policy;
• local deterministic evaluation is important; or
• the rule is specific to one implementation.

Choose remote policies when:

• security needs to change enforcement without a deployment;
• the same policy model must be deployed across multiple services or languages;
• incident response speed matters;
• authorized operators need direct ownership and the system provides the required auditability; or
• dry-run telemetry should drive a centrally managed rollout.

Use both when a consequential operation needs rich application context and central security governance. Keep stable mechanics and application invariants in code. Put changeable organization policy in the remote control plane. Do not duplicate the same rule in both places unless one is an intentional defense-in-depth backstop with documented precedence.

Implementation checklist

1. Inventory consequential operations. Name the API request, tool call, queue action, or function whose side effect must be stopped.
2. Place enforcement before execution. A policy result produced after the operation is telemetry, not prevention.
3. Classify every input. Record its source, trust level, type, sensitivity, and whether it may leave the process.
4. Define a stable contract. Use hardcoded labels and explicit typed inputs; do not derive labels from user or model output.
5. Assign rule ownership. State which controls are application-native, which are remote, and who may change each.
6. Test the side effect. Verify denial prevents execution, not merely that an SDK returned a denied result.
7. Specify failure behavior. Decide what happens on timeout, unavailable policy, stale configuration, malformed input, and partial evaluation.
8. Roll out in dry run. Measure false positives and affected actors before moving a new broad rule to live enforcement.
9. Preserve evidence safely. Record label, policy version, actor, decision, reason, and execution outcome without logging secrets or unnecessary raw content.
10. Exercise incident response. Confirm an authorized policy editor can publish an urgent restriction and engineering can diagnose its impact without an emergency application release.

For concrete input types, supported rules, local evaluation, and availability semantics, continue to the Arcjet Agent guard remote policies documentation.