AI 에이전트에 회사의 어떤 기능을 허용해야 할까?

구체적인 고객 업무에 도움이 되고 시스템이 범위를 제한할 수 있을 때, AI 어시스턴트가 회사 기능을 호출하도록 하세요. 작업, 필요한 데이터, 결과를 책임질 사람부터 정합니다. 공개 FAQ는 페이지를 더 명확하게 만드는 것으로 충분할 수 있습니다. 고객의 비공개 주문 상태에는 접근 통제가 필요합니다. 예약에는 승인과 확정 절차가 필요합니다.

‘에이전트가 호출할 수 있다’는 것은 가용성 조회처럼 회사가 제공한 기능을 어시스턴트가 이용할 수 있다는 뜻입니다. 시스템 전체에 접근하도록 허용한다는 뜻은 아닙니다.

첫 작업과 한계를 정하세요

고객이 작업 완료 여부를 자주 묻는 가상의 서비스 회사를 생각해 보세요. 첫 도구로 작업 한 건의 상태를 반환하는 기능이 유용할 수 있습니다. 다음 조건을 명시해야 합니다.

• 호출자는 해당 작업을 볼 권한이 있어야 합니다. 참조번호만 아는 것으로는 부족합니다.
• 응답에는 고객에게 공개하도록 승인된 상태, 최종 갱신 시점, 지원 경로가 포함됩니다. 내부 메모와 다른 고객의 기록은 제외합니다.
• 도구는 작업을 수정하거나 환불을 실행하거나 원본 시스템에 없는 완료 날짜를 약속할 수 없습니다.
• 원본을 이용할 수 없거나 접근에 실패하면 그 상태를 알립니다. 상태를 지어내면 안 됩니다.

다른 인터페이스를 만들기 전에 기존 고객 포털과 비교하세요. 포털이 이미 문제를 해결한다면 고객에게 어시스턴트 연결이 필요한 이유와 유지 방법을 확인하세요.

첫 버전에서는 결제, 환불, 파괴적 변경, 개인정보 대량 내보내기를 호출 범위에서 제외하세요. 기능 확장은 별도로 승인하고 테스트해야 합니다. 모델에게 올바르게 행동하라는 지침을 주는 것은 접근 통제가 아닙니다.

읽기 전용도 보호가 필요합니다

읽기 작업도 비공개 문서를 유출하거나, 다른 고객의 주문을 보여 주거나, 과거 가격을 현재 가격으로 안내할 수 있습니다. 데이터베이스 기록을 바꾸지 않더라도 고객에게 피해를 줄 수 있습니다.

접근 권한은 검증된 신원과 서버 측 권한으로 판단하세요. 어시스턴트가 보낸 account_id는 계정 소유권의 증거가 아닙니다. 같은 조직의 직원이라도 모든 문서를 볼 권한은 없을 수 있습니다.

MCP가 제공하는 것과 구현해야 할 것

Model Context Protocol(MCP)은 어시스턴트에 도구를 제공하는 한 가지 방법입니다. 아래 참고 자료는 2026년 10월 9일 확인한 2026년 7월 28일 개정판입니다. 실제 클라이언트와 서버가 지원하는 버전을 확인하세요.

인가 사양은 토큰 검증과 권한 범위를 포함한 HTTP 인가를 다룹니다. 단순히 로그인을 전달하는 것 이상입니다. 다만 부여된 권한을 허용된 작업과 기록에 연결하는 일은 구현에서 해결해야 합니다. 다른 서비스를 대상으로 발급된 토큰은 유효하더라도 받아들이면 안 됩니다.

도구 사양은 서버 측 입력 검증, 접근 통제, 호출 제한, 출력 정제를 요구합니다. 사람의 감독과 확인 요청을 권장하지만 하나의 상호작용 방식을 강제하지는 않습니다. MCP 클라이언트를 연결했다고 해서 애플리케이션의 통제가 작동한다는 뜻은 아닙니다.

보안 지침은 상태 식별자를 가지고 있다는 사실을 인증으로 취급하지 말라고도 설명합니다. 워크플로나 장바구니 참조번호는 확인할 대상을 가리킬 뿐, 누가 이용할 수 있는지 증명하지 않습니다.

승인을 구체화하고 시스템에서 강제하세요

예약을 제안할 때는 확정 전에 서비스, 시간대, 날짜, 가격, 취소 조건을 고객에게 보여 주세요. 무엇을 승인했는지 기록하고, 중요한 내용이 바뀌면 다시 승인받으세요. 모델이 만든 ‘승인됨’ 표시는 고객 동의의 증거가 아닙니다.

제안 준비와 약속 확정을 분리하세요. 초안을 저장하면서 기록을 만들거나 알림을 보낸다면 이미 쓰기 작업이므로 권한 설계에 포함해야 합니다. 서버는 정확히 그 조건에 필요한 승인이 없으면 확정을 거부해야 합니다.

저희 에이전트 호출 시스템 서비스는 읽기 도구부터 시작합니다. 의무를 만드는 작업은 마지막에 추가하고 되돌릴 수 없는 작업은 고객이 확인하도록 합니다. 저희 파일럿 구축에는 시스템 쓰기, 고객 메시지, 자금 이동에 관한 별도의 사람 승인 요건이 있습니다. 일반적인 설계 예시가 계약 범위를 넓히지는 않습니다.

출시 전에 거부와 복구를 테스트하세요

테스트 계정과 기록을 사용하세요. 다음 개발자도 재현할 수 있도록 예상 결과와 실제 결과를 함께 보관하세요.

좁게 한정한 권한, 유효기간이 있는 자격 증명, 검증된 권한 철회를 사용하세요. 보안 경계에 필요할 때 자격 증명을 분리하되, 도구마다 다른 로그인이 반드시 필요한 것은 아닙니다. 시간 제한, 재시도 횟수, 호출자별 한도를 정하세요. 쓰기에는 일관된 작업 식별자와 서버 측 중복 처리를 적용하고 모델의 기억에 의존하지 마세요.

호출자, 작업, 권한 판단, 관련 승인 참조번호, 결과를 기록하세요. 비밀 정보와 불필요한 개인정보는 가리고, 로그 접근자와 보관 기간을 정하세요. 도구를 중단하고 결과가 불확실한 작업을 확인할 운영 담당자를 지정하세요. 구매 심사를 위한 파일럿 가이드는 이런 책임을 검토 가능한 형태로 만드는 방법을 설명합니다.

저희 공개 사례가 입증하는 것

2026년 10월 9일 mcp.strataigize.com의 tools/list, 공개 인가 메타데이터, auth.md를 확인했습니다. 목록에는 공개 읽기 도구 일곱 개와 무료 성장 상담을 요청하는 인증 도구 request_growth_audit 한 개가 있었습니다. 기존 이름을 유지하고 있지만 유료 AI Opportunity Audit이 아닌 상담 신청입니다.

이 신청은 쓰기 작업입니다. 문서는 특정 사람이 요청했어야 하며 제출 내용을 사람이 검토하고 자동 예약하지 않는다고 명시합니다. 소프트웨어 클라이언트의 공개 등록과 사람의 신원 증명도 명확히 구분합니다.

이번 확인은 공개된 인터페이스와 이용 조건에 대한 것입니다. 신청을 제출하거나 보안을 시험하지 않았으며 도구 목록만으로 외부 사용이나 매출을 입증할 수 없습니다.

개발을 의뢰하기 전에 첫 고객 작업, 허용 데이터, 금지 작업, 승인 시점, 실패 테스트, 운영 담당자, 도구 철회 절차를 적으세요. 올바르게 완료된 고객 작업과 함께 거부, 예외, 검토 시간을 측정하세요. 전체 호출 수에는 재시도와 실패가 포함되므로 성공 건수가 아닙니다. AI 컨설팅을 통해 연동 개발 전에 범위를 정할 수 있습니다.