---
layout: commands
page_title: 'Commands: Intention Check'
---

# Consul Intention Check

Command: `consul intention check`

Corresponding HTTP API Endpoint: [\[GET\] /v1/connect/intentions/check](/api-docs/connect/intentions#check-intention-result)

The `intention check` command checks whether a connection attempt between
two services would be authorized given the current set of intentions and
Consul configuration.

This command requires less ACL permissions than other intention-related
tasks because no information about the intention is revealed. Therefore,
callers only need to have `service:read` access for the destination. Richer
commands like [match](/commands/intention/match) require full
intention read permissions and don't evaluate the result.

-> **Note:** This command will always treat intentions with `Permissions`
defined as _deny_ intentions during evaluation, as this endpoint is only suited
for networking layer 4 (e.g. TCP) integration.

The table below shows this command's [required ACLs](/api#authentication). Configuration of
[blocking queries](/api/features/blocking) and [agent caching](/api/features/caching)
are not supported from commands, but may be from the corresponding HTTP endpoint.

| ACL Required                  |
| ----------------------------- |
| `intentions:read`<sup>1</sup> |

<p>
  <sup>1</sup> Intention ACL rules are specified as part of a{' '}
  <code>service</code> rule. See{' '}
  <a href="/docs/connect/intentions#intention-management-permissions">
    Intention Management Permissions
  </a>{' '}
  for more details.
</p>

## Usage

Usage: `consul intention check [options] SRC DST`

`SRC` and `DST` can both take [several forms](/commands/intention#source-and-destination-naming).

#### API Options

@include 'http_api_options_client.mdx'

#### Enterprise Options

@include 'http_api_namespace_options.mdx'

@include 'http_api_partition_options.mdx'

## Examples

```shell-session
$ consul intention check web db
Denied

$ consul intention check web billing
Allowed
```
