SilentShield

에이전트 규칙 적용

적용은 SilentShield AI 에이전트 제어의 2단계입니다: AI 에이전트 방문을 기록만 하는 대신, 서버나 엣지가 키별 정책을 능동적으로 적용해 각 에이전트를 허용, 제한 또는 차단합니다. 관찰 모드 위에 그대로 쌓아 올리는 구조입니다. 시행 구성 요소(Next.js 미들웨어, sidecar 바이너리, Cloudflare Worker)는 현재 얼리 액세스로 요청 시 제공됩니다 — [email protected] 로 문의하세요.

먼저 관찰하고, 그다음 적용

저희의 분명한 권장 사항: 먼저 관찰을 활성화하고 1–2주 동안 실행한 뒤, 무언가를 차단하기 전에 리포트를 확인하세요 — Wordfence의 학습 모드나 DMARC 롤아웃(none → quarantine → reject)과 같은 단계적 방식입니다. 어떤 AI 서비스가 실제로 사이트를 방문하는지, 차단하면 무엇을 잃게 되는지(예: AI 검색에서의 인용)는 리포트만이 보여 줍니다. 이 그림 없이 적용하는 것은 눈을 감고 결정하는 것과 같습니다.

적용 방식

모든 Enforcer는 같은 계약을 공유합니다: API 키의 정책 번들을 가져와 SilentShield의 고정(pinned) 공개 키로 번들의 Ed25519 서명을 검증한 뒤, 요청 경로에서 어떤 외부 호출도 없이 로컬에서 허용, 거부 또는 제한을 결정합니다.

고정 서명 키는 https://api.silentshield.io/.well-known/silentshield-agent-keys 에서 한 번만 가져오면 됩니다. 그리고 모든 Enforcer는 fail-open으로 동작합니다: 네트워크, 서명, 만료된 번들 등 어떤 오류가 발생해도 요청은 통과됩니다. 적용이 사이트를 다운시키는 일은 절대 없습니다.

설정 방식

Next.js (엣지 미들웨어)

관찰에 사용한 것과 동일한 Next.js 어댑터가 적용도 처리합니다. 정책 환경 변수를 설정하면 미들웨어가 엣지에서 정책을 적용합니다:

.envbash
AGENT_POLICY_URL=https://api.silentshield.io/api/v1/agent/policy
AGENT_OBSERVE_API_KEY=YOUR_API_KEY
AGENT_TRUSTED_KEYS=[{"kid":"…","key":"<base64 ed25519 pubkey>"}]

리버스 프록시 (nginx / Caddy / Traefik)

작은 사이드카 바이너리 하나로 세 가지 프록시를 모두 지원합니다: 프록시가 forward auth를 통해 요청마다 한 번 물어봅니다. 사이트 키와 신뢰 키를 지정해 시작하세요:

Terminalbash
AGENT_POLICY_URL="https://api.silentshield.io/api/v1/agent/policy" \
AGENT_SITE_KEY="YOUR_API_KEY" \
AGENT_TRUSTED_KEYS='[{"kid":"…","key":"<base64 ed25519 pubkey>"}]' \
AGENT_SIDECAR_LISTEN=":8127" \
  ./agent-sidecar

사이드카는 GET /auth에 204(허용), 403(거부) 또는 429와 Retry-After(제한)로 응답합니다. 프록시에 다음과 같이 연결하세요:

nginx.confnginx
location = /_ss_auth {
    internal;
    proxy_pass              http://127.0.0.1:8127/auth;
    proxy_pass_request_body off;
    proxy_set_header        Content-Length "";
    proxy_set_header        X-Forwarded-Method $request_method;
    proxy_set_header        X-Forwarded-Uri    $request_uri;
    proxy_set_header        X-Forwarded-Host   $host;
    proxy_set_header        X-Forwarded-For    $remote_addr;
    proxy_set_header        User-Agent         $http_user_agent;
    proxy_set_header        Signature          $http_signature;
    proxy_set_header        Signature-Input    $http_signature_input;
    proxy_set_header        Signature-Agent    $http_signature_agent;
}
location / {
    auth_request /_ss_auth;
    # ... your normal proxy_pass to the origin ...
}
Caddyfilecaddy
example.com {
    forward_auth 127.0.0.1:8127 {
        uri /auth
        copy_headers User-Agent Signature Signature-Input Signature-Agent
        # Caddy sends X-Forwarded-Method/-Uri/-Host automatically
    }
    reverse_proxy origin:8080
}
traefik.ymlyaml
http:
  middlewares:
    silentshield:
      forwardAuth:
        address: "http://agent-sidecar:8127/auth"
        authRequestHeaders:
          - "User-Agent"
          - "Signature"
          - "Signature-Input"
          - "Signature-Agent"

Cloudflare Worker

Cloudflare Worker Enforcer는 Web Crypto Ed25519로 정책 번들을 검증하며, 요청이 오리진에 도달하기 전에 차단합니다:

Terminalbash
cd enforcers/cloudflare-worker
npx wrangler secret put AGENT_SITE_KEY
# set AGENT_POLICY_URL + AGENT_TRUSTED_KEYS in wrangler.toml [vars]
npx wrangler deploy

솔직한 한계

가정용 IP 주소의 에이전트형 브라우저(Comet, ChatGPT Atlas 등)는 기술적으로 사람 방문자와 구별할 수 없습니다. 어떤 제품도 이를 확실하게 식별할 수 없으며 — 그래서 SilentShield는 이 카테고리에 대해 의도적으로 어떤 적용 약속도 하지 않습니다.

robots.txt와 발행되는 콘텐츠 시그널은 권고 사항입니다: 예의 바른 크롤러는 따르지만, 강제할 방법은 없습니다. 기술적 적용은 이 페이지의 Enforcer에서만 이루어지며 — Enforcer조차 보수적으로 동작해, 확실하게 식별된 알려진 에이전트만 거부하므로 정상 방문자가 차단되는 일은 없습니다.

정책 구성

어떤 에이전트에게 무엇을 허용할지는 API 키별로 에이전트 허브에서 구성합니다: API 키 → 키 선택 → 에이전트. 프리셋이 일반적인 경우를 다루며, 변경할 때마다 새로 서명된 번들이 만들어져 Enforcer가 자동으로 적용합니다.

에이전트 허브 열기 →