---
title: Bypass prevention
description: Each way an agent could act around Veefore, how it is detected or prevented, and what risk remains.
---
The gateway enforces everything that reaches it. The question this page
answers is the other one: what reaches the outside world **without** passing
through it, and what Veefore does about that.

Prevention means the action cannot happen. Detection means Veefore finds the
path and reports it, and a fail-closed runtime stops its agent until it is
fixed.

## Scenarios

| # | Scenario | Detection | Enforcement point | Decision | Prevention possible | Residual risk |
| --- | --- | --- | --- | --- | --- | --- |
| 1 | An AI agent node wired directly to Gmail | Verifier: `AI_TOOL_BYPASS`, `DIRECT_PROVIDER_NODE`, `DIRECT_CREDENTIAL` | Managed: node allowlist. Customer: fail-closed gate | At risk; agent refused when fail closed | Managed yes; customer no | Customer instance between verifications |
| 2 | Generic HTTP Request node | `GENERIC_HTTP_NODE` (host or "expression") | Managed: allowlist + egress | At risk | Managed yes | Customer instance |
| 3 | Code node calling a provider with its own credential | `CODE_EXECUTION_NODE`, `DIRECT_CREDENTIAL` | Managed: allowlist, env blocking, egress | At risk | Managed yes | Code behaviour is not analysed; detection is by node type |
| 4 | A second connector added directly in Claude | Not visible to Veefore | None available | Runtime capped at Partial | No | Full: Veefore states it cannot see it |
| 5 | A third-party agent uses an external service to act | Not visible | Destination-side permissions only | Partial | No | Full |
| 6 | Workflow changed after verification | Two-minute sweep, definition hash | Fail-closed gate refuses unverified or drifted workflows | At risk until re-verified | Detect-then-block | Up to one sweep interval |
| 7 | Approved action modified before execution | Approval binding over parameters, tool, capability, amount, resource, policy version | Gateway | Refused | Yes | None |
| 8 | Credential revoked while an approval is pending | Broker checks status at lease time | Gateway, credential stage | Refused, no egress | Yes | None |
| 9 | Gateway or policy service unavailable | Pipeline throws | Gateway | Blocked, recorded | Yes | A runtime calling providers directly is unaffected |
| 10 | A tenant reaching another tenant's credentials or grants | Tenant-scoped repositories, agent-bound authorizations | Data layer + gateway | Not found | Yes | None known |

Scenarios 1–3, 6, 7, 8 and 10 are covered by
`tests/e2e/runtime-enforcement.test.ts`, and 1, 2, 3 and 6 also against a real
n8n 2.43.7 instance with `scripts/smoke-n8n-live.ts`. Scenario 9 is covered by
the chaos suite (database unreachable, dependencies withdrawn mid-session), and
10 also by the security suite's tenant-isolation tests.

## Remediation

Each finding carries its own remediation in the console. In general: move the
action to a Veefore tool, move the secret into the broker and delete it from
n8n, restrict editor roles, and use the managed profile where an action must be
prevented rather than detected.

## Failure behaviour

| Failure | Behaviour |
| --- | --- |
| Policy engine | Protected action blocked (`POLICY_SERVICE_UNAVAILABLE`). |
| Credential broker | Action blocked before egress (`CREDENTIAL_SERVICE_UNAVAILABLE`). |
| Approval service | Approval-gated actions cannot execute. |
| Audit persistence | The action record and audit event are written in one transaction; a failure fails the action. |
| Runtime unreachable | Verification fails; status becomes Unverified; fail-closed runtimes stop their agent. |
| Expired or revoked runtime API key | `CREDENTIAL_INVALID` finding; status Unverified. |
| Managed control failed or drifted | At risk; agent refused; operator recovery re-verifies. |
| External provider outage | Outcome `FAILED`; never reported as success. A partial effect at the provider is recorded as failed for reconciliation, not reversed. |

Fail closed means new protected actions stop. It does not undo actions that
already executed.

## Residual risks Veefore reports, and does not hide

- Customer administrators can add direct paths at any time.
- Native connectors and other code paths on third-party platforms.
- DNS exfiltration and model-provider hosts on a managed deployment.
- Attestations signed on a host that could itself be compromised.
- Static analysis does not interpret Code node logic.