ERP 보안, AI 에이전트의 발전 속도를 따라잡지 못하다

BankInfoSecurity는 AI 에이전트가 운영 권한을 확보하면서 ERP 보안 통제가 이를 따라잡지 못하고 있다는 불편한 충돌을 Google News에 제기했다.

문제는 어시스턴트가 송장을 요약하거나 조달 관련 질문에 답할 수 있는지 여부가 아니다. 에이전트가 기록을 조회하고, 도구를 호출하며, 거래를 변경하고, 여러 엔터프라이즈 시스템 전반의 작업을 조율할 수 있을 때 위험이 시작된다.

SAP, Oracle, Microsoft, Workday는 ERP 소프트웨어를 그 방향으로 이끌고 있다. 이들 에이전트는 재무, 조달, 인사, 공급망 전반에서 반복 업무를 줄이겠다고 약속한다. 그러나 이들 에이전트를 둘러싼 통제 체계는 여전히 인간 직원과 예측 가능한 애플리케이션을 전제로 설계된 가정을 물려받고 있다.

이 불일치가 핵심 보안 문제를 만든다. 기존 ERP 거버넌스는 어떤 사람이 어떤 역할을 맡고, 그 역할이 어떤 거래를 허용하는지 묻는다. 에이전틱 시스템은 위임된 목표, 변화하는 맥락, 도구 선택, 머신 간 인계 과정을 도입한다.

에이전트는 유효한 자격 증명을 보유하고도 안전하지 않은 작업을 수행할 수 있다. 또한 각각은 허용된 여러 단계를 결합해 어떤 관리자도 의도하지 않은 결과를 만들 수 있다.

ERP 공급업체들은 ID 통제, 승인 게이트, 감사 기능을 추가하고 있다. 이런 조치는 중요하지만, 에이전트 자율성과 결정론적 엔터프라이즈 통제 사이의 더 깊은 충돌을 없애지는 못한다.

Google News의 경고는 챗봇이 아니라 권한에 관한 것이다

중요한 변화는 ERP AI 에이전트가 비즈니스 데이터를 읽는 단계에서 실제로 조치를 수행하는 단계로 이동하고 있다는 점이다.

Google News를 통해 노출된 ERP 보안 보고서는 확장되는 에이전트 역량과 더딘 보안 적응 사이의 경쟁으로 문제를 규정한다.

이 구도가 중요한 이유는 ERP 시스템이 기업 운영의 사실상 진실을 담고 있기 때문이다. 이 시스템에는 지급 지시, 직원 기록, 공급업체 계약 조건, 재고 현황, 고객 잔액, 재무 승인 정보가 저장된다.

일반적인 챗봇은 잘못된 답변을 낼 수 있다. 실행 권한을 가진 ERP 에이전트는 잘못된 답변을 전기된 분개장 항목이나 승인된 공급업체 변경으로 바꿀 수 있다.

에이전틱 AI는 목표를 해석하고, 계획을 수립하며, 도구를 선택하고, 제한적인 감독 아래 여러 단계를 수행할 수 있는 소프트웨어를 의미한다. 이는 사전 정의된 경로를 따르는 고정형 자동화와 다르다.

전통적인 워크플로는 구매 주문서가 누락될 때마다 송장을 거부할 수 있다. 반면 에이전트는 불일치를 조사하고, 서신을 조회하며, 납품 기록을 비교하고, 예외 처리를 권고할 수 있다.

이런 유연성은 실제 비즈니스 프로세스에 모호성이 존재하기 때문에 가치를 만든다. 동시에 기존 보안 통제의 상당수가 의존하는 예측 가능성은 약화된다.

보안팀은 고정된 워크플로를 배포 전에 검토할 수 있다. 어떤 필드를 읽고, 어떤 시스템 호출을 수행하며, 어떤 조건에서 승인이 실행되는지 알 수 있다.

에이전트는 매번 다른 순서를 선택할 수 있다. 그 행동은 프롬프트, 사용 가능한 도구, 검색된 문서, 모델 버전, 주변 대화에 따라 달라질 수 있다.

이는 인증에서 권한 부여가 끝날 수 없다는 뜻이다. 보안은 에이전트의 ID, 위임된 목적, 현재 맥락, 선택된 도구, 요청된 데이터, 의도된 영향을 평가해야 한다.

에이전트가 애플리케이션 경계를 넘을 때 문제는 더 어려워진다. 재무 에이전트는 하나의 작업을 완료하기 전에 이메일, 조달 기록, 고객 데이터, 결제 시스템을 조회할 수 있다.

각 연결은 공격 표면을 넓힌다. 또한 여러 구성 요소가 안전하지 않은 결과에 기여했을 때 책임 소재를 정하기 어렵게 만든다.

Google News 독자는 처음에는 이 이야기를 생성형 AI 정확성에 대한 또 하나의 경고로 해석할 수 있다. 하지만 근본적인 문제는 더 중대하다.

ERP 보안팀은 수동적인 애플리케이션보다는 고도로 연결된 직원에 가까운 방식으로 행동하는 소프트웨어를 통제해야 한다. 이 직원은 지속적으로, 기계 속도로, 조직 경계를 넘나들며 작동할 수 있다.

이 변화는 최고정보보안책임자, ERP 관리자, ID 팀, 내부 감사인, 비즈니스 프로세스 책임자에게 부담을 준다. 이들 어느 한 집단도 위험을 혼자 관리할 수 없다.

보안팀은 접근 통제를 이해하지만 세부적인 프로세스 맥락이 부족할 수 있다. 재무 책임자는 중대한 영향을 이해하지만 모든 기술적 종속성을 파악하지 못할 수 있다.

ERP 관리자는 역할과 거래를 이해한다. 그러나 워크플로에 연결된 외부 모델, 에이전트 프레임워크, 서드파티 도구를 통제하지 못할 수 있다.

따라서 당면 과제는 기술적인 동시에 조직적인 문제다. 기업에는 최초 지시부터 그에 따른 모든 조치까지 에이전트를 추적하는 하나의 통제 모델이 필요하다.

ERP AI 에이전트는 인간 ID 모델을 무너뜨린다

소프트웨어가 목표를 재해석하고 자체 실행 경로를 선택할 수 있게 되면, 유효한 ID만으로는 조치의 적절성을 증명할 수 없다.

ERP 통제는 전통적으로 실명 사용자, 할당된 역할, 직무 분리를 중심으로 이루어졌다. 직무 분리는 한 사람이 민감한 프로세스의 양립할 수 없는 단계를 통제하지 못하도록 막는다.

예를 들어 공급업체를 생성하는 직원은 해당 공급업체에 대한 지급을 독립적으로 승인해서는 안 된다. 이 규칙은 사기를 제한하고 탈취된 자격 증명의 영향을 줄인다.

에이전트는 권한이 여러 계층을 거쳐 전달될 수 있기 때문에 이 모델을 복잡하게 만든다. 한 사람이 에이전트에 지시하고, 에이전트는 다른 에이전트를 호출하며, 그 에이전트는 비즈니스 애플리케이션을 호출한다.

최종 시스템에는 인증된 서비스 ID만 보일 수 있다. 원래 사용자, 목적, 증거 또는 요청에 부여된 제한은 전달받지 못할 수 있다.

이는 위임 체인 문제를 만든다. 각 시스템은 자신의 직접 호출자만 인식하는 반면, 조치의 완전한 출처와 의도는 재구성하기 어려워진다.

공유 에이전트 자격 증명은 문제를 더욱 악화시킨다. 여러 워크플로가 하나의 서비스 계정을 사용하면 조사 담당자는 정상적인 자동화와 오용을 구분하기 어려울 수 있다.

지속적인 자격 증명은 권한이 본래 목적보다 오래 유지되도록 할 수도 있다. 임시 조정 프로젝트를 위해 만든 에이전트가 작업 종료 후에도 접근 권한을 유지할 수 있다.

인간의 접근 권한 검토는 일반적으로 고용 관련 이벤트와 고정 역할을 중심으로 이뤄진다. 에이전트는 직원보다 훨씬 빠르게 나타나고, 변경되고, 복제되고, 사라질 수 있다.

또한 정식 개발 프로세스 밖에서 구성될 수도 있다. 비즈니스 팀은 모델을 승인된 도구에 연결하면서도, 그 조합이 새로운 특권 ID를 만든다는 사실을 인식하지 못할 수 있다.

OWASP의 에이전틱 보안 프레임워크는 ID 및 권한 오용을 핵심 위험 중 하나로 지목한다. 또한 목표 탈취, 도구 오용, 에이전틱 공급망 취약점을 강조한다.

목표 탈취는 악의적이거나 신뢰할 수 없는 콘텐츠가 에이전트가 달성하려는 목표를 바꿀 때 발생한다. 유해한 지시는 문서, 메시지, 웹 페이지 또는 도구 응답 안에 포함될 수 있다.

이는 독립형 어시스턴트보다 ERP 환경에서 더 위험하다. 에이전트는 이미 기밀 기록과 거래 기능에 접근할 수 있기 때문이다.

공급업체 이메일을 읽는 조달 에이전트를 생각해 보자. 탈취된 메시지는 모델에 공격자가 통제하는 은행 계좌를 우선 처리하거나 내부 구매 데이터를 공개하도록 지시할 수 있다.

그 요청은 사용자의 원래 목표와 충돌할 수 있다. 그러나 보호 장치가 데이터와 지시를 분리하지 못하면 에이전트는 삽입된 텍스트를 관련 운영 맥락으로 취급할 수 있다.

최소 권한 원칙은 여전히 필요하지만, 구현은 더 정밀해져야 한다. 에이전트에는 하나의 목적과 하나의 제한된 기간에 필요한 권한만 부여해야 한다.

Oracle의 보안 운영 가이드는 이 구분을 명확히 한다. 분석 에이전트는 둘 다 하나의 워크플로에 참여한다는 이유만으로 조달 승인 권한이 필요하지는 않다.

이 원칙은 익숙하게 들리지만, 에이전트는 집행을 더 어렵게 만든다. 작업이 시작된 뒤 계획이 진화할 수 있고, 실행 중 추가 도구를 요청할 수 있기 때문이다.

정적 역할만으로는 목적, 거래 금액, 데이터 민감도, 신뢰도, 또는 다른 에이전트가 요청을 시작했는지 여부 같은 조건을 완전히 표현할 수 없다.

따라서 기업은 조치가 이루어지는 순간에 정책 검사를 수행해야 한다. 이 검사는 요청된 작업과 이를 둘러싼 맥락을 모두 평가해야 한다.

영향이 큰 조치에는 인간 의도에 대한 더 강력한 증거도 필요하다. 검토자가 동일한 에이전트가 만든 다듬어진 요약만 본다면 확인 버튼은 충분하지 않다.

검토자에게는 원본 증거, 제안된 변경 사항, 정책 예외, 예상 비즈니스 영향이 필요하다. 그렇지 않으면 인간 감독은 형식적인 절차가 된다.

진정한 상충 관계는 자율성과 통제 사이에 있다

에이전트 자율성이 높아질수록 ID, 정책 집행, 관측 가능성, 복구에 대한 부담도 커진다.

ERP AI 에이전트는 예외를 처리할 수 있을 때 유용해진다. 그러나 예외는 바로 결정론적 통제가 가장 적게 적용되는 영역이다.

고정형 자동화는 개발자가 미리 정의한 경로를 따른다. 에이전트는 불완전한 정보를 해석하고 어떤 경로가 적절해 보이는지 결정한다.

이 차이는 보안상의 상충 관계를 만든다. 에이전트를 지나치게 엄격히 제한하면 기존 워크플로를 위한 값비싼 인터페이스가 된다. 더 넓은 권한을 부여하면 그 오류도 운영상 결과를 낳게 된다.

에이전트가 공급업체의 클라우드 안에 머물러도 이 충돌은 사라지지 않는다. 통제된 환경은 노출을 줄일 수 있지만, 조치의 수용 가능 여부는 여전히 비즈니스 로직이 결정한다.

에이전트에게 공급업체 기록을 업데이트할 권한이 있을 수 있다. 그렇다고 모든 공급업체 업데이트가 정당한 목적에 부합하는 것은 아니다.

에이전트는 저위험 기능을 결합해 고위험 순서를 만들 수도 있다. 송장 읽기, 공급업체 생성, 지급 준비는 각각 따로 평가하면 관리 가능해 보인다.

그러나 함께 사용되면 전체 사기 경로를 재현할 수 있다. 이는 안전해 보이는 구성 요소가 안전하지 않은 결합 결과를 만드는 구성적 위험으로 불리기도 한다.

보안 도구는 개별 API 호출을 검사하는 경우가 많다. 모든 단계를 승인하면서도 이를 연결하는 더 큰 계획을 놓칠 수 있다.

에이전트 메모리는 또 다른 어려움을 만든다. 메모리는 소프트웨어가 상호작용 전반에 걸쳐 작업 맥락, 선호도, 이전 관찰을 유지하도록 한다.

이런 연속성은 성능을 향상시킬 수 있다. 그러나 악의적 지시, 민감한 데이터, 잘못된 가정을 시스템에 유입된 세션 이후까지 보존할 수도 있다.

검색 증강 생성, 즉 RAG는 모델이 응답하거나 조치를 취할 때 선별된 엔터프라이즈 정보를 제공한다. 그 보안은 검색된 자료의 출처, 권한, 품질, 최신성에 달려 있다.

오염된 지식 소스는 기반 모델을 직접 침해하지 않고도 이후 의사결정을 왜곡할 수 있다. 오래된 정책 문서는 일반적인 운영 실패를 통해 비슷한 결과를 만들 수 있다.

이 때문에 정보 거버넌스는 AI 에이전트 보안의 일부가 된다. 팀은 에이전트가 어떤 소스를 사용하는지, 누가 이를 변경할 수 있는지, 검색된 증거가 의사결정에 어떤 영향을 미치는지 알아야 한다.

내부 워크플로를 구축하는 직원에게도 신뢰할 수 있는 문서화가 필요합니다. 검색 가능한 지식 기반은 팀이 에이전트 배포와 관련된 설계 결정, 위협 모델, 승인 요건을 보존하는 데 도움이 될 수 있습니다.

문서화가 기술적 통제를 대체할 수는 없습니다. 다만 에이전트의 담당자가 바뀌거나 파일럿 단계에서 프로덕션으로 전환될 때 핵심 가정이 사라질 가능성은 줄일 수 있습니다.

도구 접근 권한은 또 다른 위험을 만듭니다. 도구는 모델 출력을 데이터베이스 조회, 메시지 전송, 비즈니스 레코드 수정 같은 행동으로 변환합니다.

연결된 도구가 이미 자격 증명을 보유하고 있다면 모델에 직접적인 데이터베이스 자격 증명이 필요하지 않습니다. 따라서 도구는 에이전트의 실질적인 권한 경계의 일부가 됩니다.

보안 검토에서는 도구 스키마, 입력 검증, 자격 증명 저장, 출력 필터링, 실패 시 동작을 살펴봐야 합니다. 모델만 검토하면 실행 경로의 대부분을 놓치게 됩니다.

멀티 에이전트 시스템은 불확실성을 더욱 키웁니다. 한 에이전트는 조사를 위임하고, 다른 에이전트는 정책을 해석하며, 세 번째 에이전트는 거래를 실행할 수 있습니다.

각 인계 과정에서 맥락이 사라지거나 신뢰할 수 없는 출력이 유입될 수 있습니다. 또한 피해를 초래한 결정을 어느 구성 요소가 내렸는지 불분명해질 수 있습니다.

SAP가 공개한 보안 아키텍처는 신원 확인, AI 처리, 비즈니스 실행, 포렌식 로깅 전반에 걸친 에이전트 요청 흐름을 추적합니다.

이러한 엔드투엔드 관점은 올바른 방향입니다. 하지만 아키텍처 다이어그램만으로 모든 고객 배포 환경이 통제를 일관되게 적용한다는 사실이 입증되지는 않습니다.

ERP 환경에는 커스텀 코드, 레거시 통합, 인수된 시스템, 외부 파트너, 장기간 유지되는 예외가 존재합니다. 이러한 차이는 공급업체의 기본 보안 모델을 약화시킬 수 있습니다.

가장 어려운 배포는 하이브리드 환경에서 발생할 것입니다. 에이전트는 현대적인 클라우드 서비스에서 시작하더라도, 권한이 광범위하고 텔레메트리가 제한적인 오래된 애플리케이션을 통해 행동할 수 있습니다.

이런 환경에서는 가장 새로운 구성 요소가 체인에서 가장 약한 통제를 그대로 물려받을 수 있습니다. 에이전트 자율성은 조직이 이미 관리에 어려움을 겪던 기술 부채를 증폭시킵니다.

감사 로그만으로는 모든 에이전트 결정을 설명할 수 없다

ERP 보안에는 사용자 의도, 에이전트 추론, 도구 호출, 데이터 변경, 비즈니스 결과를 연결하는 증거가 필요합니다.

기존 감사 로그는 익숙한 질문에 답합니다. 어떤 계정이 시스템에 접근했는지, 언제 거래가 발생했는지, 어떤 필드가 변경되었는지를 보여줍니다.

에이전트 기반 워크플로에는 더 긴 증거 사슬이 필요합니다. 조사 담당자는 요청을 시작한 사용자, 위임된 목표, 모델 버전, 검색된 맥락, 정책 결정, 도구 호출, 최종 결과를 알아야 합니다.

에이전트가 무엇을 거부했는지도 알아야 할 수 있습니다. 반복적으로 거부된 요청은 탐색 시도, 잘못된 구성 또는 손상된 소스를 드러낼 수 있습니다.

모든 프롬프트와 응답을 기록하는 일은 쉬운 해결책이 아닙니다. 프롬프트에는 급여 기록, 계약서, 개인정보, 자격 증명, 기타 제한 정보가 포함될 수 있습니다.

따라서 완전한 로그는 또 다른 민감한 저장소가 될 수 있습니다. 보존, 접근, 암호화, 마스킹 규칙은 기반이 되는 비즈니스 데이터와 일치해야 합니다.

모델 추론은 또 다른 복잡성을 제기합니다. 생성된 설명은 시스템이 실제로 출력에 도달한 방식을 정확히 나타내지 못하면서도 그럴듯하게 들릴 수 있습니다.

보안팀은 서술형 설명을 증거로 취급해서는 안 됩니다. 입력, 도구 요청, 정책 평가, 그에 따른 상태 변화를 검증 가능한 기록으로 확보해야 합니다.

이는 관측 가능성의 의미를 바꿉니다. 모니터링은 단순히 모델 가용성이나 API 오류가 아니라 전체 워크플로 전반의 행동을 포착해야 합니다.

유용한 신호에는 예상치 못한 도구 선택, 비정상적인 거래량, 일반적인 업무 범위를 벗어난 접근, 반복적인 정책 거부, 민감한 레코드 변경 등이 포함됩니다.

기준선도 에이전트에 할당된 목적을 반영해야 합니다. 급여 대사 에이전트와 소싱 에이전트가 동일한 정상 행동 프로필을 공유해서는 안 됩니다.

속도 제한은 실수의 피해 범위를 줄일 수 있습니다. 그러나 소수의 고가치 행동이 정당한지는 판단할 수 없습니다.

거래 임계값은 또 다른 계층을 제공합니다. 하지만 공격자는 활동을 더 작은 행동으로 나누거나, 하나의 저가 변경이 이후 손실을 가능하게 하는 프로세스를 악용할 수 있습니다.

기업은 여러 지점에 통제가 필요합니다. 에이전트 런타임은 도구를 제한해야 하고, 신원 계층은 권한을 제한해야 하며, ERP는 비즈니스 규칙을 검증해야 합니다.

그다음 독립적인 모니터링이 실제로 무엇이 일어났는지 검증해야 합니다. 동일한 에이전트에 행동, 평가, 자체 행동 보고를 모두 맡기면 신뢰가 지나치게 집중됩니다.

되돌릴 수 없거나 중요한 행동에는 사람의 승인이 여전히 유용합니다. 그러나 검토자는 조작을 탐지할 수 있도록 충분한 시간과 맥락을 제공받아야 합니다.

승인 피로는 보호 장치를 형식적인 절차로 바꿀 수 있습니다. 기계 속도로 작동하는 에이전트는 직원이 신중하게 평가할 수 있는 양보다 더 많은 검토 요청을 생성할 수 있습니다.

위험 등급에 따른 자율성은 더 실용적인 모델을 제공합니다. 영향이 작고 되돌릴 수 있는 작업은 자동으로 진행할 수 있지만, 민감한 행동에는 독립적인 검증이 필요합니다.

저위험 작업의 예로는 설명 초안 작성, 증거 수집, 이상 징후 표시가 있습니다. 고위험 작업에는 지급 정보 변경, 자금 집행, 접근 권한 수정이 포함됩니다.

되돌릴 수 있는지 여부는 통제 수준에 영향을 미쳐야 합니다. 잘못된 보고서는 수정할 수 있지만, 외부 지급이나 삭제된 레코드는 지속적인 피해를 만들 수 있습니다.

NIST 위험 프로필은 거버넌스, 매핑, 측정, 관리를 중심으로 AI 위험 업무를 구성합니다. 이러한 수명주기 접근 방식은 일회성 승인보다 ERP 에이전트에 더 적합합니다.

에이전트의 도구, 모델, 데이터 소스, 권한 또는 비즈니스 목적이 바뀌면 위험도도 변합니다. 각 수정은 재평가와 표적화된 테스트를 촉발해야 합니다.

테스트에는 적대적 입력과 현실적인 비즈니스 예외가 포함되어야 합니다. 정제된 데이터를 중심으로 만든 시연은 상충하는 지시 아래에서 에이전트가 어떻게 행동하는지 보여주지 못합니다.

팀은 부분 실패도 테스트해야 합니다. 에이전트가 한 단계를 완료한 뒤 다음 단계를 기록하기 전에 다운스트림 시스템의 시간이 초과될 수 있습니다.

반복 실행이 중복 효과를 만들지 않도록 하는 멱등성이 없다면, 에이전트는 복구 과정에서 같은 거래를 다시 제출할 수 있습니다.

이러한 일상적인 신뢰성 문제는 재무 기록, 접근 권한 또는 규제 대상 데이터에 영향을 미칠 때 보안 문제가 됩니다. 에이전트 안전성은 시스템 엔지니어링과 분리된 상태로 남아 있을 수 없습니다.

공급업체 가드레일과 맞춤형 ERP 현실의 충돌

SAP와 Oracle은 자체 에이전트 플랫폼을 보호할 수 있지만, 실질적 위험을 결정하는 통합, 역할, 데이터, 예외는 여전히 고객이 통제합니다.

ERP 공급업체는 구조적 이점을 갖고 있습니다. 이들은 자신의 애플리케이션 모델을 이해하며, 기존 신원, 워크플로, 감사 서비스와 나란히 에이전트를 내장할 수 있습니다.

네이티브 에이전트는 외부 모델에는 없는 비즈니스 메타데이터를 상속받을 수 있습니다. 또한 화면을 통해 사용자 행동을 모방하는 대신 승인된 인터페이스를 사용할 수 있습니다.

Oracle은 고객에게 에이전트 책임을 분리하고 협업하는 에이전트 전반에 최소 권한 원칙을 적용하라고 권고합니다. SAP는 신원 확인, 테넌트 격리, 출력 검증, 포렌식 감사 추적을 설명합니다.

이러한 통제는 실제 우려를 다룹니다. 또한 내장형 에이전트가 느슨하게 연결된 서드파티 자동화보다 안전하다는 공급업체의 주장을 뒷받침합니다.

그러나 이 주장은 한계가 있습니다. 대부분의 대규모 조직은 표준 구성만 사용하는 하나의 깔끔한 ERP 환경을 운영하지 않습니다.

이들은 여러 시스템에 걸쳐 맞춤형 프로세스를 운영합니다. 일부 애플리케이션은 온프레미스에 남아 있고, 다른 애플리케이션은 퍼블릭 클라우드나 공급업체 관리형 서비스에 위치합니다.

파트너, 계약업체, 은행, 물류 제공업체, 인수된 사업 부문은 같은 프로세스에 연결될 수 있습니다. 각 경계는 서로 다른 신원 및 통제 모델을 도입합니다.

네이티브 재무 에이전트도 이메일을 통해 신뢰할 수 없는 콘텐츠를 받을 수 있습니다. 서드파티 문서 파서에 의존하거나, 결과를 오래된 결제 애플리케이션으로 전송할 수도 있습니다.

전체 워크플로의 신뢰성은 이러한 종속성만큼만 보장됩니다. 공급업체 보안 문서는 모든 고객 확장을 고려할 수 없습니다.

외부 에이전트는 다른 절충점을 제시합니다. 이들은 경쟁하는 ERP, CRM, 커뮤니케이션, 분석 플랫폼 전반의 업무를 조정할 수 있습니다.

이러한 독립성은 공급업체 종속을 줄이고 더 폭넓은 워크플로를 지원할 수 있습니다. 동시에 사용자와 비즈니스 레코드 사이에 또 하나의 신원, 오케스트레이션 계층, 도구 생태계를 추가합니다.

따라서 실질적인 선택은 안전한 네이티브 소프트웨어와 안전하지 않은 외부 소프트웨어 사이의 선택이 아닙니다. 두 접근 방식 모두 위험을 만들지만, 그 위험은 서로 다른 곳에 집중됩니다.

네이티브 에이전트는 ERP 공급업체의 플랫폼, 클라우드, 거버넌스 모델에 신뢰를 집중합니다. 외부 에이전트는 커넥터, 자격 증명, 모델, 오케스트레이션 도구 전반에 신뢰를 분산합니다.

보안팀은 범주 라벨을 그대로 받아들이기보다 전체 행동 경로를 평가해야 합니다. 네이티브 제품도 광범위한 구성을 통해 안전하지 않게 될 수 있습니다.

외부 제품은 좁게 범위가 정해진 단기 권한만 받고 민감한 거래를 직접 완료할 수 없다면 위험을 줄일 수 있습니다.

조달 검토는 이러한 차이를 반영해야 합니다. 표준 소프트웨어 설문지는 위임 깊이, 메모리 동작, 프롬프트 처리, 도구 수준 권한을 포착하는 경우가 드뭅니다.

구매자는 ERP 로그에 어떤 신원이 표시되는지, 그리고 그것이 원래 사용자를 식별하는지 물어야 합니다. 또한 에이전트 인계 전반에서 정책이 어떻게 작업을 따라가는지도 물어야 합니다.

그 밖의 핵심 질문은 모델 업데이트, 유지되는 맥락, 데이터 레지던시, 사고 대응, 상세 텔레메트리에 대한 고객 접근과 관련됩니다.

공급업체는 관리자가 에이전트를 즉시 중단하는 방법을 설명해야 합니다. 이 통제는 단순히 인터페이스를 숨기는 데 그치지 않고, 활성 자격 증명을 철회하고 대기 중인 행동을 중단해야 합니다.

고객에게는 변경 관리에 관한 증거도 필요합니다. 모델, 시스템 프롬프트, 도구 정의 또는 검색 소스가 변경된 후 에이전트의 행동은 달라질 수 있습니다.

기존 애플리케이션 업데이트는 보통 결정론적 코드를 변경합니다. 모델 업데이트는 주변 워크플로가 그대로여도 결정을 바꿀 수 있습니다.

따라서 보안 테스트는 배포 후에도 계속되어야 합니다. 팀은 의미 있는 구성 요소가 변경될 때마다 대표 작업과 악용 사례를 실행해야 합니다.

버전 간 결과를 비교하고 회귀를 조사할 수 있는 충분한 증거를 보존해야 합니다. 6개월 전에 통과한 테스트는 변경된 에이전트에 대해 거의 말해주지 못합니다.

경쟁 압력은 이러한 규율을 약화시킬 수 있습니다. ERP 공급업체는 고객의 에이전트 도입을 원하고, 비즈니스 리더는 측정 가능한 생산성 개선을 원합니다.

신원 및 모니터링 시스템이 준비되기 전에 보안팀은 광범위한 파일럿을 승인하라는 압박을 받을 수 있습니다. 이런 순서는 거버넌스를 사후 보완 프로젝트로 만듭니다.

더 안전한 롤아웃은 범위가 제한된 작업과 관측 가능한 결과에서 시작합니다. 조직이 에이전트 행동을 설명하고, 탐지하고, 되돌릴 수 있게 된 후에만 권한을 확대합니다.

ERP 보안이 따라잡는지 보여줄 세 가지 신호

다음 단계는 에이전트별 신원, 행동 수준의 집행, 실제 프로덕션 사고에서 나온 증거에 의해 결정될 것입니다.

첫 번째 신호는 ERP 플랫폼이 각 에이전트와 위임된 작업마다 구분되는 단기 신원을 채택하는지 여부입니다. 공유 서비스 계정은 예외가 되어야 합니다.

성숙한 설계는 워크플로 전반에 걸쳐 원래 사용자, 에이전트 신원, 목적, 권한을 보존합니다. 다운스트림 애플리케이션은 행동을 허용하기 전에 이 맥락을 받아야 합니다.

이것은 ERP AI 에이전트가 확립된 책임 구조 안에서 작동할 수 있다는 주장을 강화할 것입니다. 광범위한 자격 증명에 계속 의존한다면 그 주장은 약화될 것입니다.

두 번째 신호는 공급업체와 고객이 거래 수준에서 정책을 집행하는지 여부다. 도구 사용 권한이 가능한 모든 도구 출력에 대한 권한으로 확대되어서는 안 된다.

통제는 거래 유형, 가치, 목적지, 출처 증거, 되돌릴 수 있는지 여부를 고려해야 한다. 민감한 작업에는 실행 모델 외부에서 이루어지는 독립적인 검증이 필요하다.

보안팀은 제품 출시를 검토할 때 구체적인 집행 기능에 주목해야 한다. 책임 있는 AI에 관한 마케팅 문구는 구성 가능한 통제와 내보낼 수 있는 로그보다 유용성이 떨어진다.

또한 이러한 통제가 연결된 애플리케이션 전반에서 작동하는지도 살펴봐야 한다. 한 공급업체의 인터페이스에만 한정된 보호는 크로스플랫폼 워크플로를 포괄하지 못한다.

세 번째 신호는 공개 인시던트 보고의 품질이다. 운영 환경의 실패 사례는 이론적 아키텍처가 실제 비즈니스 환경에서 어디서 무너지는지를 드러낼 것이다.

유용한 공개 자료는 침해된 ID, 조작된 입력, 영향을 받은 도구, 승인되지 않은 작업, 격리 방법을 식별해야 한다. 단순히 AI 오류라고 모호하게 언급하는 것은 방어자에게 도움이 되지 않는다.

인시던트는 사람의 승인이 존재했는지, 존재했다면 왜 실패했는지도 명확히 해야 한다. 이 증거는 감독이 위험을 줄이는지, 아니면 책임만 이전하는지를 보여줄 것이다.

에이전트가 이 세 가지 통제보다 더 빠르게 확산된다면 Google News 경고의 핵심 주장은 더욱 강해질 것이다. 반대로 ID, 집행, 증거 관리가 함께 성숙한다면 그 주장은 약화될 것이다.

조직은 큰 손실이 발생할 때까지 자체 노출 수준을 파악하는 일을 미뤄서는 안 된다. 먼저 ERP 프로세스에 연결된 모든 에이전트를 나열하는 것부터 시작할 수 있다.

그 목록에는 소유자, 목적, 모델, 도구, 데이터 소스, 자격 증명, 승인 지점, 중단 절차가 포함되어야 한다. 파악되지 않은 항목은 즉시 조사해야 한다.

다음으로 팀은 지시부터 최종 거래까지 영향이 큰 몇 가지 워크플로를 추적해야 한다. 결제 변경, 액세스 권한 부여, 분개 입력, 직원 기록 업데이트가 좋은 출발점이다.

이 작업은 시스템 간에 누락된 맥락을 드러낼 것이다. 또한 하나의 자격 증명이나 도구가 비즈니스 작업에 필요한 수준보다 더 큰 권한을 보유한 지점도 밝혀낼 것이다.

이후 기업은 작업을 영향도와 되돌릴 수 있는지 여부에 따라 분류해야 한다. 읽기 전용 리서치에는 자금 집행이나 마스터 데이터 변경과 동일한 통제가 필요하지 않다.

마지막으로 보안 책임자는 에이전트가 잘못된 방식으로 동작할 때 조직이 어떻게 대응하는지 테스트해야 한다. 격리 없는 탐지는 가장 중요한 질문을 답하지 못한 채 남긴다.

관리자는 에이전트를 중지하고, 권한을 철회하며, 증거를 보존하고, 작업을 되돌리고, 피해가 확산되기 전에 영향을 받은 기록을 식별할 수 있는가?

ERP 보안은 자율성을 없앨 필요가 없다. 자율성이 무제한 권한으로 바뀌지 않도록 보장해야 한다.

실질적인 다음 단계는 간단하다. 운영 중이거나 계획된 에이전트 워크플로 하나를 선택해, 그 워크플로가 접하는 모든 ID, 도구, 데이터 소스, 승인을 추적하라. 팀이 그 연결 고리를 설명할 수 없다면, 해당 에이전트는 더 광범위한 액세스 권한을 받을 준비가 되지 않은 것이다.

누가 이를 중단할 수 있는지, 어떤 증거가 남는지, 어떤 작업을 되돌릴 수 있는지 물어야 한다. 그 답은 또 하나의 세련된 시연보다 더 중요하다.

Google News는 이 경고를 부각했다. 이제 엔터프라이즈 팀은 ERP 통제가 사람만큼 신중하게 에이전트도 관리하고 있는지 판단해야 한다.