Azure OpenAI의 Content Filter: Safety Theater가 실제 작업을 차단할 때

Source: Dev.to

문제

함수 호출을 위한 도구를 정의할 때, 특정 용어가 전혀 악의적이지 않은 상황에서도 Azure의 콘텐츠 필터에 의해 차단됩니다:

• run script → 차단
• click element → 차단
• fill form field → 차단

이들은 Playwright, Puppeteer, Selenium 등 모든 브라우저 자동화 도구에서 표준적인 동작입니다. Azure 필터는 이를 위협으로 간주합니다.

해결 방법

해결책은 놀라울 정도로 간단합니다: 중립적인 동의어를 사용합니다.

동일한 의도를 중립적인 언어로 표현하면 즉시 통과됩니다.

왜 중요한가

필터는 프롬프트 자체의 일부로 도구 이름과 설명을 검사합니다. 키워드에 대한 패턴 매칭을 수행할 뿐 실제 위험을 분석하지 않습니다. 예를 들어, 폼 제출을 자동화하는 clickElement라는 도구는 차단되지만, 같은 도구를 activatePageItem이라고 부르면 통과됩니다. 필터는 추가적인 안전성을 제공하지 않으며, 개발자에게 완곡어법을 강요할 뿐입니다.

Google Gemini와의 비교

동일한 도구 정의를 Google Gemini 모델에 테스트해 보니 절차적 표현에 전혀 마찰이 없었습니다. 도구는 예상대로 작동했으며 어휘를 정제할 필요가 없었습니다. 이는 어느 한 공급자가 “덜 안전”하다는 문제가 아니라, Azure가 실제 보호는 거의 제공하지 않으면서 정당한 개발자를 불편하게 만드는 안전 연극을 구현하고 있기 때문입니다.

더 깊은 문제

악의적인 의도를 가진 사람은 언제든지 완곡어법을 그대로 사용할 수 있습니다. 필터는 나쁜 행위자를 막지 못하고, 정당한 사용 사례에만 마찰을 추가합니다.

진정한 안전은 다음에 기반합니다:

• 상황과 의도 이해
• 속도 제한 및 모니터링
• 사용자 인증 및 감사 로그
• 명확한 서비스 약관과 집행

키워드 차단은 요리 사이트에서 “칼”이라는 단어를 금지하는 것과 같은 보안 수준입니다.

실용적인 조언

Azure OpenAI 함수 호출을 사용해 도구를 구축한다면:

• 배포 전에 도구 이름에 트리거 단어가 있는지 감사하세요.
• 설명에서는 중립적이고 추상적인 용어를 사용하세요.
• 실제 API 호출로 조기에 테스트하세요—플레이그라운드와 동작이 다를 수 있습니다.
• 번역 매핑을 문서화하여 팀이 이해하도록 하세요.

정제된 도구 정의 예시

{
  "name": "activatePageItem",
  "description": "Activates an interactive item on the page at the specified coordinates",
  "parameters": {
    "type": "object",
    "properties": {
      "x": { "type": "number", "description": "Horizontal position" },
      "y": { "type": "number", "description": "Vertical position" }
    }
  }
}

더 자연스러운 (차단된) 버전

{
  "name": "clickElement",
  "description": "Clicks an element on the page at the specified coordinates",
  "parameters": { ... }
}

결론

Azure의 함수 호출용 콘텐츠 필터는 개선이 필요합니다. 상황 분석 없이 키워드만 패턴 매칭하는 방식은 개발자에게 마찰을 주면서 보안 이점은 거의 제공하지 못합니다. 상황이 바뀔 때까지 간단한 해결책은 바로 이렇습니다: 완곡어법을 사용하세요. 여러분의 브라우저 자동화 도구는 “버튼을 클릭”하는 것이 아니라 “인터랙티브 페이지 항목을 활성화”합니다.

원본은 javieraguilar.ai에서 게시되었습니다.