Identity for AI Agents - Patrick Riley & Carlos Galan, Auth0

• Một sản phẩm mới với các tính năng lớn như Token Vault và Async Auth đã được ra mắt, tập trung vào việc quản lý danh tính và ủy quyền cho các tác nhân AI.
• Thách thức chính là đảm bảo an toàn cho các tác nhân AI tự động, yêu cầu chúng phải biết danh tính người dùng, có thể gọi API thay mặt họ, yêu cầu xác nhận và được cấp quyền truy cập chi tiết.
• Công ty cung cấp một tầm nhìn bốn trụ cột để giải quyết các thách thức này, kết hợp với các giải pháp như Token Vault và Async Auth để giải phóng con người sử dụng công nghệ AI một cách an toàn.

• Bản phát hành sản phẩm mới (GA) giới thiệu các tính năng cốt lõi như token vault (kho lưu trữ mã thông báo) và async auth (xác thực không đồng bộ) để hỗ trợ danh tính và ủy quyền cho tác nhân AI.
• Tầm nhìn xoay quanh bốn trụ cột: tác nhân AI cần biết danh tính người dùng, cần gọi API thay mặt người dùng, có thể yêu cầu xác nhận của người dùng, và quyền truy cập của chúng phải có kiểm soát truy cập chi tiết (fine-grained access control).
• Async Auth là một cơ chế cho phép tác nhân AI khởi tạo yêu cầu ủy quyền và gửi thông báo đến người dùng để xác nhận các hoạt động rủi ro hoặc quan trọng, sau đó nhận lại mã thông báo truy cập đã được chấp thuận.
• Token Vault là tính năng quản lý mã thông báo làm mới tài nguyên upstream, hỗ trợ trao đổi mã thông báo cho kiểm soát truy cập chi tiết và quản lý vòng đời của các mã thông báo trong các khung làm việc tác nhân khác nhau.
• Khái niệm MCP server (máy chủ MCP) mới được giới thiệu, mô hình hóa nó như một client có thể giao tiếp với các API upstream và các tác nhân khác, tạo ra một security stack mạnh mẽ.
• Workshop thực hành hướng dẫn xây dựng một ứng dụng Next.js agent tích hợp các công cụ MCP, sử dụng truy cập liên kết thông qua OIDC và quản lý client developer keys.
• Bản demo chatbot ban đầu cho thấy tầm quan trọng của việc thêm danh tính và ủy quyền, vì nếu không có chúng, tác nhân AI không thể nhận biết người dùng hoặc truy cập các dịch vụ bên ngoài.

• tác nhân AI — AI agent
• GA — General Availability (có sẵn rộng rãi)
• token vault — token vault (kho lưu trữ mã thông báo)
• async auth — async auth (xác thực không đồng bộ)
• kiểm soát truy cập chi tiết — Fine-grained Access Control (FGA)
• API — Application Programming Interface (Giao diện lập trình ứng dụng)
• mã thông báo làm mới — refresh token
• mã thông báo truy cập — access token
• máy chủ MCP — MCP server
• Identity Provider (IDP) — Nhà cung cấp danh tính

Giới thiệu Sản phẩm và Các Tính năng Mới

Hôm nay chúng ta sẽ nói về danh tính cho các tác nhân AI và cách chúng ta ủy quyền cho các tác nhân cũng như các máy chủ TP và những thứ tương tự. Chúng tôi thực sự đã ra mắt một sản phẩm mới trong tuần này, điều đó đã khiến bài thuyết trình này trở nên thú vị. Một bản phát hành lớn với nhiều tính năng này đã được ra mắt vài ngày trước dưới dạng GA (General Availability) và nhiều tính năng khác. Ngoài ra, tôi nên nói trước rằng nhiều tài liệu của buổi hội thảo này đã được điều chỉnh lại. Kiến trúc sư của chúng tôi, Bobby Schick, với biệt danh Siam Shrek, đã chuẩn bị phần lớn nội dung này và chúng tôi đã sắp xếp lại thành bài thuyết trình này.

Vâng, chúng ta sẽ đi sâu vào từng chủ đề này và một số tính năng cốt lõi của bản phát hành mới, cho dù đó là token vault (kho lưu trữ mã thông báo) hay async auth (xác thực không đồng bộ). Chúng ta sẽ không đi sâu vào FGA (Fine-grained Access Control - kiểm soát truy cập chi tiết) nhưng hãy biết rằng có một sản phẩm phụ khác, nếu bạn muốn, xoay quanh kiểm soát truy cập dựa trên vai trò (role-based access control). Có một dự án phần mềm mã nguồn mở (OSS) xoay quanh kiểm soát truy cập chi tiết (fine-grained access control), thực sự mở rộng tập hợp tính năng này, nhưng đó là một chủ đề khác. Vâng, đó là một số điều chúng ta sẽ nói đến.

Giới thiệu Người trình bày và Tầm nhìn

Giới thiệu nhanh, đây là lần đầu tiên tôi tham dự hội nghị AI này, cảm ơn các bạn. Đây là một tuần tuyệt vời và tôi đã học hỏi được rất nhiều. Vâng, tôi đến từ Raleigh, không thực sự là một vùng đất thần tiên nhưng đây là một chút về tôi và vâng, thật tuyệt vời. Tôi đến từ Otsura (từ Red Hat) và chúng tôi đã học hỏi rất nhiều về không gian danh tính trong bốn năm qua. Bây giờ tôi xin nhường lời cho Carlos.

Chào mọi người, tôi là Carlos, đồng chủ trì với Patrick trong buổi hội thảo hôm nay. Lần đầu tiên tôi đến New York, lần đầu tiên đến Mỹ. Cảm ơn vì sự chào đón nồng nhiệt. Tôi thường ở Mallorca, Tây Ban Nha – một hòn đảo xinh đẹp nếu bạn biết. Tôi đã gia nhập Alzira và Octaar hơn hai năm rồi.

Tôi muốn bắt đầu bằng tầm nhìn mà Octaar và Alzira chia sẻ: Giải phóng mọi người để sử dụng công nghệ một cách an toàn. Một điều thú vị là đây là tầm nhìn có trước kỷ nguyên tác nhân AI và vẫn còn giá trị, bởi vì bản chất của chúng tôi là như vậy. Chúng tôi xử lý danh tính cho công nghệ quá khứ, hiện tại và tương lai.

Để nói một chút về thách thức. Như tôi đã nói, tầm nhìn của chúng tôi là giải phóng mọi người để sử dụng bất kỳ công nghệ nào, nhưng điều đó không có nghĩa là tất cả các công nghệ đều giống nhau và có cùng những thách thức. Rõ ràng là các tác nhân mang đến những thách thức và mối đe dọa mới, và để minh họa điều này, hãy xem danh sách OSLLF top 10 được cập nhật. Vì vậy, bạn có thể thấy những điều mới chưa từng tồn tại trước đây. Vâng, rõ ràng chúng ta cần giải quyết những vấn đề mới.

Tầm nhìn về Tác nhân AI và Bốn Trụ cột

Vậy thì, cách chúng tôi mô hình hóa và suy nghĩ về các tác nhân tại Alzira. Cho đến nay, chúng ta đã thấy các tác nhân tương tác, chatbot, trình chỉnh sửa mã, nhưng điều này không phải là tương lai. Chúng ta bắt đầu thấy các phương thức khác mà các tác nhân không còn hoạt động theo cách tương tác nữa. Đó là các tác nhân chạy nền hoặc tác nhân tự động (autonomous agents) – điều này đang rất phổ biến. Nhưng ngoài ra, chúng tôi thấy một tương lai nơi các tác nhân hoàn toàn tự động (fully autonomous agents) có thể thực hiện mọi việc thay mặt người dùng, hoặc có thể chỉ vì các tác nhân sẽ bắt đầu giao tiếp với các tác nhân khác.

Vì vậy, đây là bốn trụ cột mà chúng tôi tin rằng sẽ bao quát tất cả các phương thức mới này:

1. AI cần biết bạn là ai (Who you are): Đây là yếu tố then chốt. Nếu tác nhân không biết bạn là ai, nó không bao giờ có thể áp dụng bất kỳ biện pháp bảo mật, kiểu điều phối orchestration, ủy quyền (authorization) hay xác thực (authentication) nào, bởi vì nó là một nguồn hoặc tác nhân ẩn danh không được tin cậy trong hệ thống, và điều này rất quan trọng.
2. AI cần gọi Giao diện lập trình ứng dụng (API) thay mặt người dùng: Rõ ràng là các tác nhân sẽ đủ tự động, nhưng điều đó không có nghĩa là chúng sẽ hoạt động đơn độc. Chúng sẽ tự mình thực hiện mọi việc. Cuối cùng, chúng sẽ cần truy cập các dịch vụ khác để sử dụng các tài nguyên khác.
3. AI có thể yêu cầu sự xác nhận của người dùng: Sớm hay muộn, tác nhân sẽ cố gắng làm điều gì đó cần sự quan tâm hoặc điều gì đó mà tôi, với tư cách người dùng, không nghĩ tác nhân nên tự mình thực hiện mà không có bất kỳ sự giám sát nào từ phía tôi.
4. Quyền truy cập của AI phải có kiểm soát truy cập chi tiết (fine-grained access control): Tôi cần cấp quyền kiểm soát cho tác nhân để truy cập các tài nguyên của tôi, nhưng không phải bất kỳ tài nguyên nào, không phải bất kỳ bộ sưu tập hoặc tài liệu nào. Tôi phải là người quyết định tác nhân có thể truy cập những gì và không thể truy cập những gì.

Và để giới thiệu thêm về cách Octa và Auxedo (tức Ossia) có thể bổ sung cho nhau. Chúng ta đã nói về một người dùng và đó có thể là tôi, có thể là bạn, nhưng cuối cùng đó sẽ là một nhân viên trong một tổ chức hoặc công ty. Trong trường hợp này, nhân viên không chỉ hành động thay mặt cho chính họ mà còn đại diện cho công ty của họ. Và trong những trường hợp đó, công ty cũng cần kiểm soát chính xác những gì các tác nhân đang hành động thay mặt cho những nhân viên đó đang làm. Đó là nơi Octa cũng đóng một vai trò quan trọng. Và ở phía bên kia, Auxedo (tức Ossia) với các năng lực và tính năng mà chúng tôi đã triển khai, tôi nghĩ đó là nơi chúng kết nối. (Câu hỏi từ khán giả): Liệu đây có phải là quyền mà tác nhân có thể truy cập hay ai có quyền truy cập vào tác nhân? (Trả lời): Tôi muốn nói là cả hai. Vâng. Chúng ta sẽ đề cập đến cả hai khía cạnh này. Vâng, đúng vậy. Và sẽ có thời gian cho các câu hỏi ở cuối buổi, chắc chắn rồi. Cảm ơn. Được rồi, bây giờ chúng ta hãy đi sâu vào chính xác những gì chúng ta sẽ trình bày hôm nay.

Async Auth: Yêu cầu Xác nhận từ Người dùng

Chúng ta đã nói về bốn trụ cột. Không theo một thứ tự cụ thể nào, nhưng tôi sẽ giới thiệu một trong số đó, đó là AI có thể yêu cầu sự chấp thuận của tôi. Để thực hiện điều đó, chúng tôi đã triển khai tính năng Async Auth (xác thực không đồng bộ) như một phần của gói giải pháp xác thực cho các tác nhân AI. Về cơ bản, tính năng này tạo ra một cơ chế và giao thức để tác nhân liên hệ với người dùng khi một hoạt động cần được con người chấp thuận trong quy trình này.

Nó có vẻ đơn giản. Về bản chất thì đúng vậy, nhưng đây là một vấn đề bảo mật. Nó được xây dựng dựa trên xác thực do máy khách khởi tạo (client-initiated authentication). Xin lỗi, ý tôi là một giao thức xác thực do máy khách khởi tạo. Đây là một đặc tả RITC. Trong kịch bản này, chính tác nhân là bên khởi tạo quá trình xác thực và ủy quyền (authentication and authorization). Vì vậy, tác nhân đang chạy, có thể là một tác nhân tự động chạy dài hạn. Và tại một thời điểm nào đó, nó cần thực hiện một giao dịch mua hàng hoặc làm điều gì đó được gắn cờ là rủi ro. Với Async Auth và một đoạn mã SDK đơn giản, nó có thể khởi tạo một yêu cầu ủy quyền (authorization request) mà sẽ hiện thực hóa thành một thông báo gửi đến người dùng. Người dùng nhận được chi tiết giao dịch đó, được cấu trúc tốt. Người dùng xác nhận, chấp thuận điều đó. Và sau đó, sự chấp thuận đó được gửi trở lại tác nhân dưới dạng một mã thông báo truy cập (access token). Và mã thông báo truy cập đó chứa đựng các chi tiết chính xác mà người dùng đã chấp thuận. Vâng, tôi sẽ nhường lời lại cho Patrick để nói về client. Tuyệt vời. Vâng, câu hỏi hay. Cảm ơn các câu hỏi của các bạn.

Token Vault: Quản lý Mã thông báo và Luồng Trao đổi

Token vault (kho lưu trữ mã thông báo) là một tính năng chính khác mà chúng tôi đang giới thiệu trong bản phát hành Ossia tập trung vào AI này. Token vault là một cơ chế mới để duy trì các mã thông báo làm mới (refresh tokens) tài nguyên upstream của bạn. Bạn có thể đã sử dụng Ossia trước đây cho các nhà cung cấp mạng xã hội (social providers) hoặc Intangent với các nhà cung cấp danh tính (identity providers) khác. Điều này giúp các trường hợp sử dụng với các sự kiện dễ dàng hơn rất nhiều. Vì vậy, chúng tôi có một luồng kiểm soát truy cập chi tiết (fine-grained flow) thực sự cho phép bạn trao đổi các mã thông báo. Thay mặt người dùng, tôi có thể gửi mã thông báo truy cập (access token) của mình hoặc mã thông báo làm mới (refresh token) của ứng dụng, dù là cho một Giao diện lập trình ứng dụng (API) hay cho ứng dụng của tôi, và sau đó tôi có thể yêu cầu các phạm vi (scopes) cho một dịch vụ upstream. Cho dù đó là truy cập Giao diện lập trình ứng dụng (API) của Slack, Giao diện lập trình ứng dụng (API) của Facebook hay bất kỳ Giao diện lập trình ứng dụng (API) dựa trên danh tính nào khác.

Vâng, và chúng tôi thực sự duy trì các phạm vi. Chúng tôi quản lý vòng đời của các mã thông báo. Chúng tôi xử lý rất nhiều ở đó để đảm bảo rằng việc sử dụng SDK của bạn rất dễ dàng. Và tác nhân của bạn luôn trực tuyến, sẵn sàng và an toàn. Vâng, chúng tôi đã thử nghiệm luồng này rất rộng rãi, nhưng bạn có thể hình dung được những gì đang diễn ra under the hood (trong hậu trường). Vâng, chúng ta sẽ nói nhiều hơn về token vault trong phần thực hành. Mọi thứ sẽ có ý nghĩa hơn rất nhiều khi chúng ta đi sâu vào.

Tuy nhiên, tôi muốn nhấn mạnh một vài luồng, nơi tôi đã đề cập đến mã thông báo làm mới (refresh token) và mã thông báo truy cập (access token). Khi chúng tôi xem xét từng khung làm việc tác nhân (agent framework), bạn có thể thấy rằng, à, nó có thể khác nếu bạn đang sử dụng một single page app (SPA), đúng không? Và bạn không có một backend an toàn tương đương hoặc bạn muốn truy cập một Giao diện lập trình ứng dụng (API) bên ngoài. Trong những trường hợp này, đặc biệt là với Lengra, chúng tôi sử dụng mã thông báo truy cập (access token). Chúng tôi có mã thông báo truy cập có thời hạn ngắn. Điều này đơn giản là vì Lengra thiết lập một Giao diện lập trình ứng dụng (API) bên ngoài. Có một luồng Lengra để gọi xung quanh giao diện dòng lệnh (CLI) của Lengra. Vì vậy, trong trường hợp này, chúng tôi đã mô hình hóa luồng đó. Trong khi ở các luồng khác, bạn có thể chỉ có một ứng dụng native hoặc một ứng dụng web Next.js thông thường, một ứng dụng web truyền thống với tác nhân của bạn chạy nhúng. Thì vâng, trong trường hợp này, mã thông báo làm mới (refresh token) có thể phù hợp hoàn hảo với trường hợp sử dụng của bạn. Và sau đó, tôi nghĩ như chúng ta sẽ nói sau, cũng có những trường hợp mà, bạn biết đấy, có thể bạn có một tác nhân không đồng bộ truy cập dữ liệu khác. Chúng tôi hiện có một cơ chế mới gọi là custom API client (máy khách API tùy chỉnh), có thể cho phép một máy chủ MCP (MCP server), chẳng hạn, truy cập dữ liệu từ xa.

Vì vậy, đó là những gì chúng tôi đã làm về mặt khái niệm tại Auth0. Chúng tôi đã lấy tác nhân, mô hình hóa nó như một client, và chúng tôi đã lấy các Giao diện lập trình ứng dụng (API) của bạn, mô hình hóa chúng như các máy chủ tài nguyên OAuth (OAuth resource servers) truyền thống hoặc Giao diện lập trình ứng dụng (API) trong nền tảng của chúng tôi. Vâng, đó là một chút về những gì đang diễn ra ở đây. Tôi đã liệt kê một số chi tiết về trao đổi mã thông báo (token exchange) trên slide. Vâng, chỉ cần biết rằng loại mã thông báo chủ thể (subject token type) là loại trao đổi, cho dù là mã thông báo truy cập (access token) hay mã thông báo làm mới (refresh token), mã thông báo chủ thể là mã thông báo của bạn. Mã thông báo người dùng có thể được trao đổi để lấy mã thông báo của bên thứ ba.

Và đây là một ảnh GIF rất nhanh về luồng ngắt (interrupt flow) của chúng tôi với Lengra. Tôi mới viết cái này gần đây, vì vậy nó chỉ cho thấy cơ chế hoạt động như thế nào. Nếu lời nhắc (prompt) nói, bạn biết đấy, tôi cần truy cập lịch của mình. Chúng tôi có một nhà cung cấp mạng xã hội (social provider) của Google. Chúng tôi có một luồng ngắt. Bạn biết đấy, phần này của SDK của chúng tôi sẽ thông báo cho bạn rằng bạn cần yêu cầu thêm các phạm vi (scopes). Sau đó, chúng tôi thực hiện trao đổi mã thông báo (token exchange) từ token vault, cung cấp cho bạn một mã thông báo truy cập (access token) mới, và sau đó bạn có thể truy cập nhà cung cấp upstream của mình. Giờ nay, điều này thực sự khá đơn giản trong khung làm việc của chúng tôi.

MCP: Mô hình Client và Thiết lập Hội thảo

Và nói nhanh về MCP, sau đó chúng ta sẽ đi sâu vào buổi hội thảo. MCP là một khái niệm rất mới đối với chúng tôi. Chúng tôi vừa ra mắt phiên bản preview. Nhưng chúng tôi đã tích cực phát triển nó trong một thời gian khá dài. Vâng, bạn có thể thấy rằng chúng tôi đã mô hình hóa máy chủ MCP (MCP server) cũng như một client. Và vâng, có những trường hợp mà tác nhân (Agent) là một client nói chuyện với máy chủ MCP (MCP server), bản thân nó cũng là một client, nói chuyện với các Giao diện lập trình ứng dụng (API) upstream. Và đó chính là nơi tôi sẽ trình bày hôm nay. Nhưng vâng, luồng này khá tương tự và chúng ta sẽ nói thêm về ngữ nghĩa của MCP. Và bạn biết đấy, cách chúng tôi đã triển khai đăng ký máy khách động (Dynamic Client Registration) và những gì chúng tôi có ở đây. Những điều này hoàn toàn đến từ các đồng đội của chúng tôi. Chúng tôi chỉ cố gắng chọn những slide yêu thích.

Và vâng, đối với buổi hội thảo, tôi nghĩ chúng ta đang lên kế hoạch trình bày tổng quan từng phần. Và nếu bạn không muốn thực hành, điều đó không sao. Bạn có thể theo dõi. Nếu bạn muốn thực hành và thích tự tay làm, điều đó cũng tốt. Và vâng, chúng tôi thực sự, thực sự đánh giá cao tất cả phản hồi của bạn. Chúng tôi có thời gian ở cuối buổi cho các câu hỏi và mọi loại phản hồi. Vì vậy, chúng tôi rất mong nhận được điều đó.

Và vâng, đây là những gì chúng ta đang xây dựng hôm nay. Về cơ bản, chúng ta đang xây dựng một ứng dụng Next.js của tác nhân. Điều tuyệt vời về nền tảng của chúng tôi là chúng ta có thể nhanh chóng xây dựng các công cụ MCP song song với tác nhân của mình trong cùng một hạ tầng. Sau đó, chúng ta có thể sử dụng client của tác nhân để giao tiếp với máy chủ MCP và sau đó tận dụng máy chủ MCP để nói chuyện với các bên thứ ba (third parties). Điều đó thực sự mạnh mẽ. Và bạn biết đấy, nó an toàn và dễ xây dựng. Chúng tôi cảm thấy khá hài lòng về một số lĩnh vực trong security stack (ngăn xếp bảo mật) ở đó.

Tổng quan về Luồng Làm việc và Thiết lập Ban đầu

Đây là một ý tưởng tổng quan về các luồng làm việc điển hình mà bạn có thể thấy trong ngành. Chúng tôi sẽ bắt đầu ngay bây giờ. Hy vọng mọi người đã nhận được liên kết. Trong khi Patrick trình bày và hướng dẫn workshop, tôi sẽ sẵn sàng hỗ trợ bất kỳ ai có câu hỏi hoặc vấn đề với workshop. Chỉ cần giơ tay, tôi sẽ đến giúp bạn. Tuyệt vời! Tôi sẽ giới thiệu tổng quan, sau đó trình bày cách thức hoạt động và chúng ta sẽ từng bước xây dựng kiến trúc liên kết này.

Phần chào mừng chủ yếu là về việc cài đặt các dependencies và lấy một client. Bước đầu tiên là chúng tôi sẽ cung cấp cho bạn một IDP gốc cho tenant của bạn. Đây là một trường hợp sử dụng cấp doanh nghiệp phức tạp hơn một chút. Giả sử bạn có một core IDP provider mà bạn kết nối để quản lý API hoặc danh tính upstream. Chúng tôi có một ứng dụng giao dịch chứng khoán giả định trông như thế này. Ý tưởng của ứng dụng này là người dùng có thể truy cập, sử dụng stock API và thiết lập danh tính của họ tại đây. Tuy nhiên, ứng dụng này cũng hiển thị một API cho các downstream consumers, agent clients và các consumers khác. Vì vậy, chúng tôi có một liên kết truy cập federated thông qua kết nối OIDC tới tenant này.

Thiết lập Client và Điều kiện Tiên quyết

Phần đầu tiên thực sự chỉ là lấy client của bạn. Tôi đã có một client, nhưng nơi bạn sẽ bắt đầu là thông qua AuthSero's stack để lấy một tenant và bắt đầu nhận client developer keys của bạn. Chúng tôi sẽ thêm xác thực vào một bước tiếp theo, nhưng tôi sẽ trình bày bước đầu tiên, nơi chúng ta có một tác nhân rất đơn giản. Sau đó, chúng ta sẽ thêm danh tính và ủy quyền.

Dưới đây là một số điều kiện tiên quyết: Node, PNPM, standard tools và AuthSero CLI. Chúng tôi sử dụng CLI để quản lý nhiều phần của stack của mình. Điều này giúp mọi thứ dễ dàng hơn. Trong demo này, chúng tôi sử dụng kết hợp Terraform và CLIs. Đây là tổng quan về mặt khái niệm và một số dependencies chính. Sau khi bạn đã tạo client và đăng ký tại đây (chúng tôi có một liên kết), bạn sẽ sẵn sàng để khởi tạo tenant của mình. Tôi sẽ nói thêm về điều đó ở bước hai.

Xây dựng Chatbot và Hạn chế Ban đầu

Hãy bắt đầu từ những bước rất cơ bản. Trong bước này, chúng ta sẽ xây dựng chatbot hạ nguồn của mình. Đây là một ứng dụng hạ nguồn mà chúng ta đang khởi tạo. Nó chưa kết nối với bất kỳ thứ gì. Chúng ta sẽ thêm upstream provider này và cấp quyền truy cập với tác nhân và công cụ. Tôi đã sử dụng OpenAI với tác nhân của mình, nhưng đối với AI, bạn sẽ cần một Open API access key. Đây là repo chứa base template. Tôi sẽ cung cấp cho bạn một branch vào cuối bài, trong đó có tất cả các thay đổi mà chúng ta thực hiện trong workshop này. Hãy cùng xem nó trông như thế nào.

Vậy là, chatbot tiêu chuẩn. Ở thời điểm này, khi bạn bắt đầu, nếu bạn cố gắng làm bất cứ điều gì khác ngoài các câu hỏi Generative AI thông thường, bạn sẽ chỉ nhận được model, không có gì khác. Nhưng phần quan trọng là nếu chúng ta cố gắng hỏi model "tôi là ai", đó là lúc model sẽ nói "tôi không biết". Tương tự, trong trường hợp này, đây là một ứng dụng giao dịch chứng khoán downstream. Nếu chúng ta cố gắng tiêu thụ dữ liệu từ trading service đó, chatbot sẽ lại nói, "tôi không biết gì cả."

Thêm Nhận thức và Xác thực cho Chatbot

Hãy khắc phục điều đó. Trước tiên, hãy cung cấp cho chatbot nhận thức về dịch vụ và các công cụ, sau đó là xác thực. Vì vậy, hãy xác thực và cho tác nhân biết người dùng là ai.

À, tôi sẽ cố gắng trình bày cùng với Patrick ở đây. Vâng, đây là tiêu chuẩn cơ bản. Tôi nghĩ bạn đã thấy điều này trong một số workshop ngày hôm nay và chắc chắn là nhiều lần trong những tuần qua. Nhưng chúng ta đang ở trong Brazil AI SDKs. Chúng tôi sẽ giới thiệu Get Stock Price tool và sau đó là phần xác thực. Vì vậy, hãy bắt đầu với những điều đơn giản. Patrick đang "gian lận" một chút vì anh ấy gọi mọi thứ đã được "đánh dấu" (stash). Sẽ không dễ dàng như vậy đối với các bạn đâu. Tuy nhiên, hãy yên tâm rằng tất cả mã ở đây đều đã được stash (lưu trữ tạm thời). Bạn không phải lo lắng về điều đó. Hãy quay lại chatbot và hỏi lại về giá cả. Các bạn có muốn thử làm theo không? Được rồi. Chà, điều đó khó phải không? Hãy hoàn thành mọi thứ nhé.

Được rồi, vậy thì hãy tạo một câu hỏi giao dịch thực tế hoặc ít nhất là câu hỏi lấy thông tin về nó. Tuyệt vời. Bây giờ chúng ta đã có chatbot và tác nhân được kết nối với upstream AI. Vâng, trong trường hợp này, đó là một dịch vụ công cộng, một public endpoint nên không cần xác thực. Được rồi. Có thêm thông tin trên trang đó, nhưng không sao đâu. Tôi định nói rằng hãy quay lại những điều quan trọng.

Truy cập Dữ liệu Cá nhân và Token Vault

Điều gì sẽ xảy ra nếu chúng ta muốn đọc dữ liệu không công khai từ upstream service, mà là dữ liệu được cá nhân hóa? Tức là dữ liệu mà tôi, với tư cách là resource owner, sở hữu. Trong trường hợp này, chúng ta sẽ sử dụng một Token Vault. Về cơ bản, khi chúng ta đăng nhập, bạn có thể quay lại chatbot không? Vâng, vâng. Cho đến nay, chúng ta chưa trải qua bất kỳ quá trình đăng nhập nào. Vì vậy, không có thông tin "tôi là ai" hay bất cứ thứ gì tương tự; đó chỉ là một phiên ẩn danh cho đến nay.

Nhưng đến một lúc nào đó, chúng ta sẽ đăng nhập. Chúng ta sẽ đăng nhập vào IDP của tác nhân. Đúng vậy. Và điều đó sẽ tạo ra một mối quan hệ tin cậy giữa chúng ta và chỉ tác nhân đó. Chúng ta cần phải tiến xa hơn. Chúng ta cần thiết lập một mối quan hệ nữa. Nó giống như một mối quan hệ ba chiều: chúng ta, upstream service và tác nhân. Vì vậy, chúng ta cần thiết lập mối quan hệ tam giác này. Chúng ta sẽ làm điều đó thông qua Token Vault. Chúng ta sẽ xác thực trước với tác nhân và đổi lại nó sẽ cấp một ID token và một access token. Một access token về cơ bản cho phép chúng ta sử dụng riêng tác nhân đó.

Nhưng chúng ta có thể sử dụng (một khi chúng ta thiết lập mối quan hệ thứ ba) access token đó để đổi lấy một upstream access token. Và đó là những gì Token Vault thực hiện. Nó làm gì? Một khi chúng ta kết nối ứng dụng upstream của chúng ta, trong trường hợp này là demo trade app, Token Vault sẽ bắt đầu lưu trữ refresh token và xử lý các vấn đề về access token. Vì vậy, chúng tôi lưu trữ refresh token, chúng tôi lưu trữ access token cho đến khi nó hết hạn, và mỗi khi tác nhân cần truy cập dữ liệu này, nó sẽ chạy refresh token grant để lấy một access token. Và access token đó được cấp lại cho tác nhân. Vâng, đó là đại khái như vậy.

Triển khai Danh tính và Ủy quyền Cơ bản

Vâng, nó cũng sẽ trình bày cách thêm xác thực cơ bản cho người dùng của bạn và sau đó thêm các yêu cầu Token Vault này từ SDK. SDK code ở đây sẽ hướng dẫn bạn qua quy trình đăng ký, Terraform, tất cả các thiết lập tenant để bạn có thể bắt đầu sử dụng các dịch vụ này, phải không? Để bạn có thể truy cập Token Vaults, bạn có thể bắt đầu sử dụng danh tính với các nhà cung cấp. Đây là một bộ tính năng rất mới. Vì vậy, bạn sẽ nhận thấy rằng trong một số cấu hình của chúng tôi, bạn đang kích hoạt tính năng connected accounts với my account API mới của chúng tôi, bạn đang thiết lập grant types cho ứng dụng client của mình, ứng dụng agent của bạn, và bạn đang cấu hình kết nối OIDC của mình.

Vâng, hãy tiếp tục và sau đó chúng ta có thể trình bày tenant. Nhưng đây là các bước chúng ta có thể áp dụng để thêm danh tính cơ bản và vâng, tôi sẽ chuyển sang bạn trong khi tôi làm điều đó. Vâng, vẫn còn tất cả các bước này, có các tham chiếu, liên kết, mọi thứ bạn cần. Thật tuyệt vời khi bạn muốn làm điều này sau này hoặc ở nhà.

Luồng Đăng nhập và Liên kết Danh tính

Được rồi, vậy thì ở thời điểm này, điều chúng ta sẽ làm là đưa nút đăng nhập vào tác nhân. Vâng, chỉ để trình bày trông nó như thế nào. Vâng, vậy thì route. Vâng, chúng ta sử dụng SDK của AuthSero cho Next.js cung cấp một middleware và một wrapper cho một route. Xin lỗi, một giây. Vâng, tôi nghĩ vậy. Ồ, nó đang phàn nàn. Xin lỗi, conflicts. Được rồi. Vâng, bạn đã thay đổi. Có đáng sợ không? Nhưng đó là vì nó đang xử lý một connected account. Tôi nghĩ chúng ta đang trong quá trình đơn giản hóa điều đó trong SDK rất nhiều. Nhưng vâng, đây là route của Next.js cho chat. Vâng, vì vậy chúng ta đã lấy trang có chat client. Vì vậy, đó chỉ là trang Next.js tiêu chuẩn của bạn. Và vâng, đây là wrapper của chúng tôi, sau đó buộc đăng nhập hoặc cung cấp cho bạn một redirect.

Vâng, đúng vậy, đúng vậy, đúng vậy, hay điều này phù hợp như thế nào? Đây là một tác nhân nhúng trong ứng dụng Next.js. Vì vậy, vâng, chatbot này là một tác nhân nhúng và chúng tôi sẽ trình bày các tác nhân bên ngoài khác. Điều bạn làm là có triển khai hiện có với các thành phần bổ sung. Bạn đang chia sẻ với tôi ngay bây giờ. Vâng, vâng, và điều gì có sẵn ngoài box? Vâng, đó thực sự là những wrapper này từ SDK, bao bọc một endpoint, cho dù đó là một page route hay thứ gì đó khác.

Vâng, thì điều này khá tiêu chuẩn với Next.js SDK của chúng tôi bây giờ. Chúng ta đã thiết lập một session. Vâng, tôi sẽ trình bày đăng nhập, nhưng thực sự không có nhiều phép màu ở đây. Tuy nhiên, chúng ta đang yêu cầu các connected accounts mới này để xem bạn có kết nối federated không. Vì vậy, đó là phần hơi khó hiểu ở đây, bởi vì, bạn biết đấy, các luồng AuthSero cũ sẽ không có điều đó. Ví dụ, chúng ta sẽ không yêu cầu upstream providers trong nhiều trường hợp hoặc các API khác. Nhưng trong trường hợp này, vâng, chúng ta đang sử dụng một federated provider. Và vâng, nó phức tạp hơn một chút. Và vâng, chúng ta đang tạo một client ở đó. Bạn có thể thấy các tùy chọn OIDC mà chúng ta đang cung cấp, vốn dành riêng cho OIDC. Và sau đó, connect account endpoint này là mới. Điều đó sẽ kích hoạt connected accounts API mới của chúng tôi để quản lý tất cả các tài khoản của bạn. Tôi nghĩ vậy, vâng, vậy thì hãy để tôi trình bày điều đó và kiểu như, vâng, hãy làm đi.

Được rồi. Đó là mã. Tôi nghĩ, vâng, hãy để tôi khởi động lại. Được rồi. Được rồi. Hãy thử lại. Vâng. Tuyệt vời. Tôi sẽ đăng xuất và đăng nhập. Vì vậy, chúng ta đăng xuất. Ở thời điểm này, bạn hoàn toàn muốn đặt một nút đăng nhập hoặc bất kỳ UX đăng nhập nào phù hợp với bạn. Trong trường hợp này, chỉ cần đơn giản kích hoạt nếu bạn cố gắng truy cập URL, nó sẽ ngay lập tức hiển thị màn hình đăng nhập.

Vì vậy, bây giờ chúng ta đăng nhập. Và ở thời điểm này, chúng ta, à, chúng ta vừa trình bày, nhưng chúng ta đang đến upstream IDP. Vâng. Vì vậy, chỉ sử dụng một bộ thông tin xác thực duy nhất. Và sau đó, ít nhất bây giờ, vâng, nó biết rằng tôi có một session. Và tôi là ai, hãy xem. Vì vậy, nó đã lấy profile từ IDP. Nó tải dữ liệu đó vào context. Vì vậy, bây giờ nó biết bạn muốn ai. Vâng. Và trong ứng dụng lớn này, đây cũng là cùng một danh tính được liên kết với stock trader. Vâng. Dashboard này. Vâng, vì vậy danh tính của bạn hiện đã được liên kết giữa các ứng dụng bạn đang sử dụng upstream provider. Và bạn cũng sẽ sớm thấy rằng chúng sẽ được liên kết với MCP tools của bạn nữa.

Cấp quyền Truy cập Tài nguyên Cá nhân thông qua Liên kết Tài khoản

Được rồi. Vậy là chúng ta đã có danh tính, chúng ta đã đăng nhập. Chúng ta có một embedded agent đang chạy cục bộ. Chúng ta còn muốn nói gì nữa trong bước này? Chúng ta đã sẵn sàng đi tiếp chưa?

Được rồi. Vậy là, tác nhân đã biết tôi là ai, nhưng nó không biết tôi sở hữu gì. Đó là gì? Nó không có quyền truy cập vào các trading service resources mà tôi sở hữu. Và vì vậy, nếu bạn quay lại, vâng, hãy trình bày điều đó, một giây. Vâng. Cái này. Vâng. Vì vậy, số dư của tôi là 10 nghìn đô la. Tôi có các lệnh gần đây này. Vâng. Vậy thì làm thế nào chúng ta có thể cấp cho tác nhân quyền truy cập vào tất cả những thứ này?

Vâng. Vậy thì bước đầu tiên là như chúng ta đã nói trước đó, chúng ta cần kết nối hai tài khoản. Vì vậy, ngay cả khi chúng ta đang sử dụng cùng một thông tin xác thực, chúng ta vẫn chưa nói rõ ràng, hoặc người dùng chưa nói rõ ràng với tác nhân, rằng tôi muốn bạn biết tôi là ai, nhưng tôi chưa cấp cho bạn quyền truy cập vào tài khoản của tôi. Vì vậy, đó là bước bạn đang thực hiện. Chúng ta đang kết nối các tài khoản. Đó là lúc chúng ta ngay lập tức sử dụng nó với các quyền bổ sung mà tác nhân cần, các scopes bổ sung này. Được rồi.

Thiết lập Quan hệ và Công cụ Truy cập

Và đó là lúc mối quan hệ được thiết lập. Vậy là giờ đây, tác nhân biết rằng nó có quyền truy cập vào các tài khoản này với chính xác các quyền đó. Không hơn, không kém. Vâng. Đúng vậy. Và vâng. Tiếp theo, tôi nghĩ đó chỉ là việc thêm một số công cụ có thể tận dụng tài khoản này. Vì vậy, tôi sẽ chuyển sang các công cụ danh mục đầu tư. Và đây là lúc đi sâu vào việc trao đổi mã thông báo. Và vâng, bây giờ chúng ta có thể bắt đầu đặt các truy vấn phù hợp hơn. Chúng ta có thể nói, bạn có thể xem danh mục đầu tư của tôi không? Vâng. Chúng ta sẽ chưa cấp cho bạn quyền truy cập để tạo đơn đặt hàng. Đó sẽ là các phần tiếp theo. Nhưng vâng, điều này cho thấy SDK của chúng ta mô hình hóa cách nhận một mã thông báo truy cập cho một kết nối khác, cách upstream (dòng trên) tận dụng các công cụ được chia sẻ và TypeScript. Tôi nghĩ điều thực sự hay ở đây là các công cụ này có thể linh hoạt. Chúng có thể được chia sẻ giữa một công cụ tác nhân hoặc một công cụ MCP. Hy vọng khung làm việc của bạn có hỗ trợ TypeScript. Đó cũng là một khả năng tổ chức công cụ rất tốt. Và vâng, nếu bạn muốn tiếp tục, tôi sẽ thêm các công cụ. Tuyệt vời. Vì vậy, tương tự như bước đầu tiên chúng ta đã làm, chúng ta sẽ tải một khóa vào tác nhân và công cụ mới. Cho đến nay, các công cụ cục bộ, chúng ta sẽ đi sâu vào phần MCP, nhưng đó là một công cụ gốc thực hiện một yêu cầu HTTP đơn giản tới dịch vụ. Nhưng công cụ sẽ có một, vậy chúng ta có thể trình bày. Vâng, xin lỗi. Vì vậy, một trong những điều khác mà chúng tôi cung cấp trong SDK của mình là cách chúng tôi kết nối hai phần này với phần ủy quyền và xác thực. Các công cụ về cơ bản lại. Vì vậy, công cụ, vâng, không phải công cụ, một lần nữa, auto, để trình bày, cái này, tools hoặc get portfolio tool. Vâng, vâng, tiếp tục. Vâng, xin lỗi. Vì vậy, tại một thời điểm nào đó, chúng ta tạo với một client và trong handler. Vâng, vâng, chỉ là một get với include history, bạn biết đấy, truy vấn, thương hiệu, tùy chọn, bổ sung ở đó. Khá đơn giản. Vâng, tôi gọi khi bạn có một client và mã thông báo, nhưng vâng, phần thú vị là, bạn biết đấy, chúng ta có thể dễ dàng tận dụng get access token for connection trong SDK của mình. Vâng, hãy để tôi trình bày điều đó. Vâng, mọi thứ được tổ chức. Đó là điều tôi muốn trình bày. Vì vậy, SDK của chúng ta cho YT, bạn cung cấp kết nối. Trong trường hợp tên upstream đó được biểu diễn trong tenant của bạn. Và đó là thứ thực hiện tất cả các bước nhảy mã thông báo. Tôi sẽ nói, tôi sẽ nói, âm thanh thứ tư của tôi. Ồ, xin lỗi. Vậy chúng ta có một tác nhân có quyền truy cập vào dữ liệu của chúng ta, trong trường hợp của chúng ta, nhưng cũng có quyền truy cập vào những gì tôi có. Tôi phải làm gì để truy cập. Điều đó tùy thuộc vào bạn, rõ ràng là công cụ được triển khai, nhưng ít nhất, điều đó đã biết chính xác những gì chúng ta có.

Quản lý Phạm vi Quyền truy cập và MCP Server

Được. Được. Vậy là chúng ta có các công cụ danh mục đầu tư, điều này thật tuyệt. Tôi đã không trình bày các phạm vi quyền, nhưng vâng, hãy yên tâm rằng như tôi không chắc MCPC thực sự nhanh chóng, vậy loại gì chúng ta đã xây dựng và mô hình hóa. Và điều này có thể giúp giải đáp một số câu hỏi, nhưng vâng, đây là máy chủ MCPC mà chúng ta đã mô hình hóa như một API. Và chúng ta có các phạm vi quyền xung quanh việc truy cập máy chủ MCPC. Chúng ta đã mô hình hóa chúng theo cùng một cách với API upstream của chúng ta. Vậy hãy xem, quyền. Chúng ta có các phạm vi quyền xung quanh việc đọc giao dịch, đọc danh mục đầu tư của chúng ta. Và vâng, những điều đó được tham chiếu trong các công cụ đó trong meta. Điều đó không hoàn toàn rõ ràng, nhưng vâng, chúng ta đang biểu diễn chúng dưới dạng các quyền có phạm vi. Vâng. Nếu bạn làm việc với trade app cho portfolio, những điều này rất cụ thể theo ứng dụng. Vâng. Vâng. Vậy làm thế nào nó biết chúng có nghĩa là gì trong ngữ cảnh của ứng dụng đó? Bạn có thể trả lời câu đó. Bạn muốn nói gì? Vậy ứng dụng này là một ứng dụng giao dịch chứng khoán. Vậy từ trade app, sẽ có ý nghĩa rất cụ thể ở đây. Vâng. Nhưng tôi có thể có một ứng dụng khác mà từ trade hoặc từ portfolio, có thể là một ứng dụng quản lý dự án, mà bạn sẽ có ý nghĩa khác? Vâng. Vậy làm thế nào nó xác định được ý nghĩa của các quyền? Hãy để tôi trả lời. Tôi nghĩ tôi hiểu, nhưng cuối cùng, chính dịch vụ upstream đặt ra các quy tắc. Đúng không? Vì vậy, nếu bạn muốn truy cập tài nguyên của tôi, tôi cần một mã thông báo truy cập với phạm vi quyền này. Nếu không, chúng tôi sẽ từ chối yêu cầu của bạn. Không quan trọng bạn là một tác nhân hay bạn không phải là một loại ứng dụng REST truyền thống. Và điều đó thực sự là bạn, với tư cách là người triển khai tác nhân, bạn biết điều đó trước. Bạn biết, nếu bạn được kết nối với một upstream, bạn biết hình dạng của yêu cầu là gì và lớp ủy quyền mà bạn cần triển khai là gì. Bạn có thể mô hình hóa phạm vi quyền của mình theo cách bạn muốn trong tenant cục bộ của mình, nhưng cuối cùng, việc dịch các phạm vi quyền này sang upstream phải được thực hiện. Vậy bạn có thể nói. Vậy tôi làm điều đó ở đâu? Nó ở trong kết nối. Vâng. Bạn sẽ tìm thấy kết nối. Vâng. Vâng, vậy kết nối cấp doanh nghiệp của chúng ta tới upstream ở đây. Và vâng, bạn có thể thấy chúng ta đang yêu cầu các phạm vi quyền đó từ tenant upstream. Và nó cũng, trong trường hợp này, có các bước đó được mô hình hóa xung quanh API chứng khoán. Vâng. Vậy những phạm vi quyền này đang được nhận trên dịch vụ đó. Vâng. Vì vậy, điều này chính xác là như vậy. Nó rất có thể công khai hoặc là một phần của hợp đồng giữa bạn và upstream. Và đó chính xác là những gì người dùng sẽ thấy trên giao diện người dùng mà bạn đã thấy vào thời điểm họ kết nối tài khoản. Chính xác. Vì vậy, chúng tôi ở đây để đơn giản hóa. Chúng tôi sử dụng cùng tên, nhưng nó có thể khác. Nó có thể là các phạm vi quyền khác nhau. Việc dịch xảy ra trên token và cả hai. Vâng. Và tôi cũng nên đề cập, chúng tôi mô hình hóa vai trò khác nhau, đúng không? Như xung quanh persona hoặc danh tính của họ. Phạm vi quyền thực sự là xung quanh truy cập API. Vì vậy, nếu bạn đang tìm cách mô hình hóa nhiều hơn xung quanh vai trò, vâng, chắc chắn hãy kiểm tra FGA. Chúng tôi có các kiểm soát truy cập dựa trên vai trò, mà bạn có thể áp dụng xung quanh các công cụ cũng như xung quanh các trang. Nhưng đây là nhiều hơn chỉ là truy cập chi tiết xung quanh một API. Vậy được rồi, hãy tiếp tục. Vâng. Vâng. Rất nhiều điều này rất mới. Nhưng kết nối đã tồn tại từ rất lâu. Nhưng mục đích, và thực ra đó là tên chúng tôi chọn, mục đích của một kết nối. Chúng tôi tạo một cái mới, đó là stockable. Được rồi, chúng ta vẫn còn khá nhiều thời gian, nhưng vâng, được rồi, sẵn sàng chuyển sang MCP. Vâng. Có câu hỏi nào cho đến nay không? Bạn có thể chuyển đổi chủ đề ở đây không? Tôi muốn hỏi bạn. Vâng. Tương tự như câu hỏi của bạn, phạm vi quyền bạn có thể nhận được từ những gì được biết đến, không có ý tưởng rằng nó khó như vậy. Đó là một cách phổ biến để sử dụng đúng thứ. Chúng tôi lấy chúng. Vâng. Vâng. Vâng, chính xác.

Đăng ký Máy khách Động (DCR) và Bảo mật Tài nguyên MCP

Vâng, bạn đã đi thẳng vào luồng tiếp theo. Và vâng, chúng tôi đã được đào tạo để triển khai đặc tả hiện tại với MCP ngay bây giờ. Và đó là phần tiếp theo của bài tập là thêm điểm cuối và siêu dữ liệu tài nguyên được bảo vệ đã biết. Và vâng, chúng tôi đã thử nghiệm điều này với rất nhiều nhà cung cấp gần đây. Và gần đây, chúng tôi vừa EA tính năng DCR của mình trong tuần này. Nhưng vâng, luồng này phức tạp hơn một chút, đúng không, bởi vì máy chủ MCP trở thành client của tác nhân. Và chúng tôi sẽ trình bày cách chúng tôi mô hình hóa điều đó trong mã linh hoạt. Và bạn có thể thấy tất cả các bước. Rõ ràng có nhiều điều liên quan hơn. Nhưng điều quan trọng là vì chúng tôi đang thực sự bảo mật tài nguyên và công cụ MCP. Và thực hiện điều đó một cách chi tiết. Nhưng cũng cho phép đăng ký động với nhiều nhà cung cấp. Vâng, chúng tôi sẽ trình bày điều đó vào cuối bài này. Vâng, tôi có thể bật cái này lên nếu bạn muốn. Vâng, bạn có thể xem trước. Vì vậy, điều này cho thấy, có thể tôi sẽ nói chuyện với bạn một chút về điều này. Điều này cho thấy một số middleware. Và cách chúng tôi áp dụng xác minh phạm vi quyền trên chính máy chủ MCP. Và cách chúng tôi phơi bày siêu dữ liệu. Vâng, đó chính xác là những gì bạn đang ám chỉ. Giống như chúng tôi quảng cáo các phạm vi quyền được hỗ trợ. Khi bạn đi đăng ký trong phần đó của luồng và sau đó, vâng, xa hơn nữa, tôi nghĩ nó nằm trong transport. Khi chúng tôi thực sự xây dựng. Vâng, đây chỉ là những hàm trợ giúp khác. Vì vậy, giống như, bạn biết đấy, tạo middleware để xác minh JWT. Chúng tôi vẫn, bạn biết đấy, vẫn là một bearer token. Mã hóa khóa công khai/khóa riêng tư. Nhưng vâng, chúng tôi tham chiếu các thư viện đó. Chúng tôi có rất nhiều thư viện chia sẻ để thực hiện những việc này ngay bây giờ. Và sau đó, vâng, một điểm quan trọng khác ở đây là đây là nơi chúng tôi giới thiệu API client tùy chỉnh này. Và có thể tôi có thể trình bày. Vì vậy, đây là một client riêng biệt mà chúng tôi đã mô hình hóa trong bản demo này. Bạn thực sự có thể tạo bất kỳ số lượng API client nào. Nếu bạn muốn mô hình hóa chúng độc lập hơn hoặc cách bạn muốn xây dựng stack của mình. Nhưng vâng, chúng tôi đã mô hình hóa điều này như một linked client, đây cũng là một tính năng mới, không phải số không. Vì vậy, giờ đây chúng tôi thực sự có thể liên kết các API với các client và mô hình hóa chúng về cơ bản bạn có thể coi chúng là một agent client hoặc một MCP server client. Vì vậy, đó là một tính năng mới thực sự hay. Những cái đó hiện đã được liên kết. Và chúng tôi cũng có hỗ trợ API cho chúng. Vâng, bạn có thể thấy cách xây dựng một API client với MCP server client ID và secret. Và vâng, tôi sẽ chạy điều đó trong giây lát. Tôi muốn xem liệu điều này có. Vậy đây là, một lần nữa, như giám sát các công cụ được chia sẻ này. Vì vậy, chúng tôi đã chuyển công cụ chứng khoán, công cụ danh mục đầu tư này từ tác nhân sang máy chủ MCP ngay bây giờ. Vì vậy, chúng tôi cũng có thể phơi bày nó từ đó. Và sau đó là việc đăng ký các công cụ. Và sau đó, vâng, đây là nơi chúng tôi tạo transport. Vậy đây là nơi chúng tôi tạo điểm cuối MCP và hợp đồng máy chủ. Và vâng, đó là nơi chúng tôi gọi middleware của mình. Vâng, hãy để tôi trình bày điều đó. Và vâng, tôi không có gì khác. Vâng, trong trường hợp này, để thêm một nỗ lực nhất định nhằm trình bày toàn bộ hành trình, chúng tôi quyết định tạo MCP như một phần của workshop này. Nhưng nó cũng có thể là bạn nhận được MCP upstream của mình, không phải là bạn đang xây dựng một MCP. Nhưng bạn vẫn cần phải ủy quyền cho điều đó, đúng không? Vì vậy, trong cả hai trường hợp, phiên làm việc đều hoạt động. Vì vậy, không phải chúng tôi muốn trình bày cả hai đầu. Đó là lý do tại sao có rất nhiều mã trong trang đó chỉ vì một phần của nó là máy chủ MCP thực tế. Vì vậy, tôi đã bỏ tất cả các thay đổi trong phần này mà tôi vừa trình bày. Và vâng, điều này về cơ bản là những gì sẽ cung cấp cho chúng ta các công cụ MCP. Vì vậy, ý tôi là, tôi sẽ bắt đầu điều này. Được rồi. Vâng, khi chúng tôi chuyển điều này cho client, trong trường hợp này, trong cùng máy chủ Next.js mà tác nhân đang chạy, đó là nơi MCP được phục vụ. Nhưng tùy thuộc vào kiến trúc của bạn, nhưng cùng nội dung được áp dụng. Vì vậy, tôi sẽ nói vâng, cứ tiếp tục đi. Vì vậy, bạn có thể thử điều đó, nhưng nó sẽ không có tác dụng vì việc bạn yêu cầu các phạm vi quyền không phải là một phần của kết nối sẽ bị bỏ qua hoặc từ chối. Vì vậy, chỉ cần bỏ qua điều đó. Vâng, nó phụ thuộc vào upstream, nhưng vâng. Vì vậy, những phạm vi quyền không phải là một phần, hãy sửa tôi nếu tôi sai, nhưng nó sẽ không. Các phạm vi quyền không phải là một phần của kết nối không bao giờ có thể kết thúc trong mã thông báo truy cập. Đúng vậy. Đúng vậy. Đúng vậy. Vì vậy, tôi nghĩ chính sách của chúng tôi hầu hết thời gian là sử dụng những gì chúng tôi không nhận ra. Vì vậy, bạn sẽ nhận được một mã thông báo truy cập với các phạm vi quyền hợp lệ, nhưng không phải cái bạn cố gắng tiêm. Và tôi cũng không nghĩ, bây giờ bạn đã đề cập, tôi không nghĩ chúng tôi phơi bày phần out cho LLM, nghĩa là chúng tôi phơi bày công cụ và chúng tôi lấy công cụ, nhưng việc ủy quyền xảy ra trước khi thực thi công cụ. Vì vậy, tôi không nghĩ LLM sẽ có bất kỳ ảnh hưởng nào đến chính xác điều gì, nhưng tôi không nói rằng điều đó không thể xảy ra vì có nhiều cách để làm nhiều việc. Nhưng dù sao, ngay cả ở phía chúng tôi, bất cứ điều gì chúng tôi không nhận ra không nên kết thúc trong mã thông báo truy cập. Bởi vì chúng tôi có nghĩa là ứng dụng sẽ thực sự nhận ra bạn có những kết nối nào trước khi nó yêu cầu hướng dẫn của bạn để có một khóa truy cập trống. Đúng vậy. Vâng. Vì vậy, khi bạn cố gắng thực thi công cụ, công cụ sẽ nói, được rồi, tôi cần một mã thông báo truy cập vì tôi cần thực hiện một cuộc gọi API. Chính grapple của chúng tôi hoặc các công cụ SDK của chúng tôi cung cấp mã thông báo truy cập này cho công cụ. Nó không phải là công cụ theo lệnh từ LLM. Điều đó chạy yêu cầu ủy quyền. Hãy để tôi nói đó chỉ là mã kiểu cũ. Nó không phải LLM.

Trình bày Đăng ký Máy khách Động (DCR)

Được rồi. Bây giờ tôi sẽ trình bày từng bước DCR. Vâng, tôi đang sử dụng MCP inspector, một công cụ phổ biến, và chúng tôi sẽ trình bày một số công cụ khác.

Truy cập Máy chủ MCP và Luồng Xác thực

Phần này sẽ trình bày cách chúng ta có thể nhắm mục tiêu trực tiếp đến máy chủ MCP (chạy trên cùng một máy chủ dưới /MCP). Điều này sẽ minh họa luồng OAuth 2.0 và quá trình Đăng ký máy khách động (DCR) đang diễn ra. Chúng tôi sẽ tiếp tục. Đây là một tuyên bố miễn trừ trách nhiệm: Open DCR là như nhau, nhưng bạn có thể thấy chúng tôi đang ở giai đoạn truy cập sớm, và tôi không nghĩ chúng tôi sẽ... Vâng, có một số lo ngại về khả năng mở rộng của điều này. Tuy nhiên, có những khía cạnh khác mà tôi nghĩ chúng ta sẽ làm tốt hơn trong kịch bản này. Hoàn toàn đồng ý.

Bạn có thể thấy siêu dữ liệu của tài nguyên được bảo vệ đang được trả về, vì vậy chúng ta có điểm cuối well-known. Bạn có thể thấy scope được hỗ trợ, sau đó chúng ta gửi yêu cầu đến máy chủ ủy quyền. Điều này trả về nhiều thông tin hơn về tenant của chúng ta và không có scope bổ sung nào ngoài những gì đã được ủy quyền.

Vì vậy, tôi sẽ bỏ qua phần đó. Sau đó, chúng ta nhận được một lệnh gọi đăng ký. Giờ đây, chúng ta sẽ nhận được một máy khách mới chỉ cho mục đích thử nghiệm với máy chủ MCP. Vâng, bây giờ chúng ta sẽ nhận được, tôi tin đây là PKCE. Đó là luồng mã ủy quyền của chúng ta với Proof Key for Code Exchange (PKCE). Vâng, đó là luồng OAuth 2.0 tiêu chuẩn, nhưng nó cũng hoạt động tốt với MCP.

Tôi sẽ sao chép điều này. Được rồi. Bây giờ, hệ thống sẽ đưa ra lời nhắc cho tôi và cung cấp một mã ủy quyền. Ở cuối dòng này, chúng ta sẽ nhận được một mã thông báo truy cập. Điều này thật tuyệt vời. Giờ đây, chúng ta có thể truy cập máy chủ MCP với các scope này từ bất cứ đâu. Đó là điều tuyệt vời. Bây giờ tôi sẽ nhấn kết nối. Hãy xem liệu chúng ta có thể nhận được một số công cụ không. Vâng, bây giờ chúng ta có quyền truy cập vào danh mục đầu tư của mình. Và các công cụ truy cập đọc và ghi của chúng ta có thể truy cập giữa cùng một API chứng khoán upstream.

Bạn có muốn thêm bất cứ điều gì ở đây không? Không. Không có câu hỏi nào ư? Vâng, tốt. Chắc chắn rồi. Được rồi. Vâng, đây thực sự là phần phức tạp nhất của luồng này. Tôi sẽ hiển thị đám mây. Tôi đã triển khai nó nếu bạn muốn thử nghiệm. Và vâng, đó thực sự là phần phức tạp nhất của MCP. Và vâng, tôi nghĩ chúng ta đã hết thời gian. Vậy hãy đi vào phần sử dụng goth. Được rồi. Bạn có muốn tiếp tục điều khiển phần lập trình không? Chắc chắn rồi.

Phê duyệt Tác nhân cho các Thao tác Rủi ro

Như chúng ta đã nói trước đây, việc tác nhân có quyền truy cập vào tài nguyên của chúng ta không có nghĩa là nó nên thực hiện bất cứ điều gì vào bất cứ lúc nào mà không có sự giám sát của tôi. Đúng không? Tôi đã nói điều này mọi lúc. Chúng ta không muốn một tác nhân tạo ra "ảo giác" mua cổ phiếu vào giữa đêm mà không có sự cho phép của tôi.

Đó là lúc gói của chúng ta cung cấp một cách đơn giản, và tôi nghĩ cách này giúp tác nhân tiếp cận người dùng và nhận được sự phê duyệt cho các thao tác rủi ro. Trong trường hợp này, chúng ta có thể thấy việc đặt lệnh mua/bán. Một thao tác rủi ro là thứ mà chúng ta, với tư cách là cộng đồng nhà phát triển, định nghĩa, và điều đó tùy thuộc vào chúng ta.

Vì vậy, trong trường hợp này, những gì chúng ta sẽ làm là chúng ta sẽ thực thi công cụ nhưng với một số điều kiện. Vâng. Những điều kiện đó sẽ là trước khi chạy công cụ, chúng ta sẽ gọi back-channel auth. Đó là tên SDK cho xác thực bất đồng bộ. Chúng ta sẽ nhận được một mã thông báo truy cập chứa chính xác những gì người dùng đang làm.

Vì vậy, hãy để tôi quay lại. Chúng ta sẽ tạo yêu cầu này tới back-channel với các chi tiết của giao dịch. Trong trường hợp này, đó sẽ chính xác là số lượng mua hoặc bán và giá để người dùng có thể xem trên màn hình, rất có thể là trên một thiết bị ngoại vi, xem và phê duyệt. Và chỉ khi được phê duyệt, chúng ta mới đặt lệnh.

Vâng, cho điều đó, trong trường hợp này, trong ví dụ, chúng ta sẽ sử dụng Guardian. Đó là ứng dụng NFA của chúng tôi. Đó là một ứng dụng sẵn có mà bạn có thể sử dụng, bạn có thể cài đặt và sử dụng. Nhưng chúng tôi cũng hỗ trợ SDK Guardian trong trường hợp bạn muốn tự triển khai. Tôi không chắc về người dùng.

Chi tiết Luồng Phê duyệt Tác nhân

Để tác nhân có thể tiếp cận người dùng, đặc biệt đối với kênh này, người dùng cần được đăng ký NFA. Có nhiều cơ chế để làm điều đó. Chỉ cho buổi workshop, chúng tôi cho bạn thấy "cửa hậu". Nhưng điều đó phụ thuộc vào UAX của bạn, cách bạn có thể thực hiện trong quá trình đăng ký, hoặc một bước xác minh nâng cao, tôi không biết. Điều đó tùy thuộc vào bạn. Nhưng chúng ta cần đăng ký. Vì vậy, bạn sẽ tìm thấy trong tài liệu, nhưng bạn sẽ tìm thấy một cách để gửi email chứa tất cả các hướng dẫn này để đăng ký.

Vì vậy, một khi chúng ta đăng ký, chúng ta có thể thêm hàm trợ giúp nhỏ này ở đây, về cơ bản nó chỉ chuyển tiếp xác thực (auth) đến SDK UAX. Hãy để tôi hoàn tác và áp dụng lại ở đây. Tôi có đi nhanh quá không? Không, hoàn hảo. Tôi đang theo kịp. Được rồi. Vậy thì, trong một giây, tôi sẽ cho bạn thấy chính xác những gì chúng ta sẽ gửi trong quá trình ủy quyền này. Được rồi.

Vậy chúng ta có thể thấy. Tôi nghĩ nó nằm trong Austria. Chúng ta thêm... Vâng. Đây là hàm trợ giúp. Nó chỉ là một lớp bao bọc để gói các tiêu đề và tất cả các thứ khác. Nhưng về cơ bản nó lại là điều này. Đó là dòng mã trong SDK của chúng tôi. Đó là những gì chúng ta gửi và những gì sẽ chạy tất cả các bước này một cách nội bộ. Nó sẽ hiển thị công cụ, nó sẽ chờ phản hồi của người dùng. Vì vậy, về cơ bản nó là một thao tác bất đồng bộ. Và khi người dùng phản hồi, tác nhân có thể tiếp tục. Nó nằm trong công cụ. Vâng. Cái này cũng vậy. Vâng, cái này.

Ở đây chúng ta đang tạo một máy khách mới với... Chúng ta đang chỉ định những gì chúng ta cần trong chi tiết ủy quyền. Vì vậy, chúng ta có thể cung cấp chi tiết yêu cầu ủy quyền mở rộng đó khi yêu cầu ủy quyền đến. Chúng ta đang sử dụng máy khách API tùy chỉnh này. Trong trường hợp này, chúng ta đã tạo, bạn có thể tạo các máy khách khác. Nhưng vâng, chúng ta đang tạo một máy khách API tùy chỉnh để sau đó thực hiện yêu cầu kênh phụ. Và sau đó, vâng, trong trường hợp này, nó chờ. Bạn có thể làm nhiều thứ khác nhau. Bạn có thể thăm dò. Có những cơ chế khác ở đây. Nhưng vâng, trong trường hợp này để đơn giản, chúng ta chờ xác minh. Vì vậy, hãy để tôi thử điều này. Được rồi.

Tương tác với Tác nhân và Thông báo Người dùng

Được rồi. Vậy chúng ta chạy lại. Tác nhân chatbot sẽ quay lại đây. Được rồi. Giờ đây chúng ta có thể yêu cầu... Tôi không biết. Vâng. Chờ một cái khác. Nó là gì? Wain? Vâng. Ví dụ: cổ phiếu giả định. Vâng, trong trường hợp này, vâng. Cứ tiếp tục đi. Vâng, vâng, vâng, vâng. Tôi rất vui được chia sẻ điều đó tới... Bạn muốn tôi chia sẻ bây giờ hay sau? Được rồi. Vâng, vâng. Chúng tôi có một nhánh trạng thái cuối cùng. Vâng.

Trong trường hợp này, tác nhân được chỉ dẫn để thông báo cho người dùng rằng điều này sắp xảy ra. Vì vậy, đây chưa phải là yêu cầu ủy quyền. Nó chỉ là một cảnh báo cho người dùng: "Bạn sẽ nhận được một thông báo. Không sao đâu. Đó chỉ là một hệ thống thực sự ngớ ngẩn từ máy khách." Vì vậy, bạn có thể tiếp tục. Sau đó... Vâng, chờ đợi. Khoan đã. Nên được kết nối. Để tôi xem. Ồ. Được rồi. Một phút. Cho tôi một giây. Bạn có muốn để nó một chút thời gian không? Vâng. Tắt nó đi. Ồ, tôi xin lỗi. Để tôi thử lại. Để tôi xem. Vâng. Đang làm mới. Đang làm mới.

Ngoài vô số thông báo, chúng tôi cũng hỗ trợ email là một kênh. Và nhiều kênh khác, chúng tôi sẽ triển khai thêm các kênh thông qua nhau. Vâng. Có lẽ tôi cần khởi động lại ứng dụng. Trong tổ chức. Có phải đó là mong muốn của tôi rằng các người dùng làm việc được ủy quyền trước? Trong việc ủy quyền. Vâng, ý tôi là, tôi đoán là tùy thuộc vào bạn cách bạn quản lý phiên với Eurasian. Không, tôi chắc chắn không ai khác có thể tương tác với cùng một công cụ. Vâng, vâng. Tôi có thể là tác nhân được ủy quyền trước cho một số quyền truy cập nhất định không? Nhưng cũng cho người được ủy quyền có thể sử dụng một ứng dụng. Chỉ là không hiểu tất cả các trường hợp sử dụng khác nhau xung quanh đó. Vâng, nhưng điều này tùy thuộc vào bạn cách bạn quản lý các phiên và quyền để truy cập ứng dụng như một tài nguyên. Nhưng một khi bạn thiết lập điều đó, thì vâng, bạn có thể sử dụng dịch vụ và chính sách là một. Cuối cùng, tôi không biết liệu mình có theo kịp bài kiểm tra không. Chúng ta có thể dịch ngay bây giờ. Tôi đã phê duyệt nó.

Vâng, tôi đã phải kết nối lại ở mạng này. Vậy, được rồi, để tôi thử thêm một lần nữa. Nó đã đến. Chỉ là một ví dụ cho tác nhân này nói rằng, tác nhân có hỏi liệu nó có được phép truy cập trang web đó không. Vì vậy, tôi chỉ muốn đảm bảo rằng tác nhân đã thất bại. Được rồi. Đó là những gì tôi biết về các trang web. Đó là ý tôi về ba trang web cụ thể. Khi bạn nói trang web, bạn nói dịch vụ đó. Chúng ta đã bị đe dọa API hoặc các công cụ nhất định. Chỉ cố gắng xem liệu có bất cứ điều gì có thể xảy ra trong sự kiện không. Bởi vì hiện tại ứng dụng đã diễn ra một cách tương tác. Vâng. Vì vậy, tôi chỉ nói rằng nó có thể, bạn biết đấy. Tôi hiểu rồi. Vâng. Vì vậy, bạn biết đấy, đây là cách tôi nhìn nhận. Tôi biết. Tôi không. Tôi không có quyền truy cập vào bất kỳ người nào. Tôi hiểu. Tôi hiểu rồi bây giờ. Tôi hiểu rồi bây giờ.

Vâng, tôi cũng có những lo ngại tương tự. Tôi không làm việc về sản phẩm, xin lỗi. Nhưng vâng, hãy tưởng tượng rằng giao diện của bạn không phải là một chatbot. Nó giống như một trình chạy tác vụ. Vì vậy, tôi đoán những gì tôi sẽ triển khai với tư cách là một kỹ sư là tôi sẽ đính kèm định danh của mình, hoặc ít nhất là một định danh của người dùng, chủ thể vào tác vụ đó trong cơ sở dữ liệu của tôi. Vì vậy, tôi nhập tác nhân. Tôi thiết lập một tác vụ và tôi nói, được rồi. Tôi muốn, tôi không biết, tìm cho tôi một món hời tốt hoặc tư vấn cho tôi hoặc mua cổ phiếu Wayne khi giá dưới 70. Vâng. Đó có thể là một tác vụ, đúng không? Tôi nghĩ tác vụ đó được mô hình hóa trong hệ thống của bạn, đúng không? Nó phải được mô hình hóa theo một cách nào đó. Tôi không biết liệu đó là lời nhắc và ý tưởng của người dùng. Và điều đó, đó là khi bạn thiết lập điều đó.

Vì vậy, và chúng tôi sử dụng người dùng. Đó là chủ thể. Đó là những gì chúng tôi sử dụng để xác định xem người dùng có kết nối với tài khoản đó hay không. Bạn biết đấy, vì vậy tôi cần tài khoản này, người dùng này đã ngắt kết nối điều này. Tôi hiểu. Và sau đó tôi sẽ chỉ. Và sau đó nó có một định danh cho tác nhân vì tôi muốn đánh giá cao kết nối của một tác nhân nào đó hoặc nhận xét từ người dùng. Nhưng đó là một điều. Bạn đang trong xác thực (auth) của chúng tôi. Sự kiện là một tác nhân thực hiện yêu cầu đến dịch vụ. Nó nằm trong tài khoản của tôi. Vậy tôi cần gì. Vậy. Nhưng tôi muốn biết cho ứng dụng. Vì vậy, tôi muốn phân biệt. Sự kiện tác nhân đã bị tắt? Tôi muốn biết tác nhân đã bị tắt, đúng không? Vì vậy, tôi muốn biết. Vâng, bạn có thể. Bạn có thể làm điều đó. Vâng.

Trong trường hợp đó, vì tác nhân là máy khách, mã thông báo truy cập của bạn sẽ có một bên ủy quyền (authorization party). Đó là một xác nhận (claim) không xác định người dùng, mà là ai. Ai mà người dùng đang ủy quyền truy cập cho. Và đó là nơi bạn có thể nói, được rồi, đây là ID của tôi với tư cách là một tác nhân. Đây là chủ thể của tôi. Vì vậy, bây giờ tôi có thể chính xác, được rồi, tác nhân này thực sự sẽ có những người dùng này. Và bạn có thể thực hiện bất kỳ chính sách nào bạn cần trên đó. Vâng. Đó là tất cả. Điều đó không có gì mới. Nó đã tồn tại mãi mãi. Nhưng bây giờ tôi hiểu. Vâng.

Định danh Tác nhân và Chi tiết Yêu cầu Ủy quyền Mở rộng

Ngoài ra, vâng, tôi muốn hiển thị các nhật ký và chỉ... Chúng tôi đã hiển thị quá trình trao đổi trong ví dụ trước để truy cập danh mục đầu tư, nhưng đây là luồng xác thực và quá trình trao đổi token thực tế, hơi khác một chút trong nhật ký của chúng tôi. Nhưng tôi nghĩ nó cũng liên kết mọi thứ lại với nhau rất tốt. Và nó cho thấy, bạn biết đấy, tôi sẽ cho thấy một tải trọng mã thông báo thực tế trông như thế nào. Một lần nữa, giả định và các mã thông báo này sẽ không cung cấp cho bạn...

Đây là những chi tiết tôi đang nói đến. Chúng tôi sử dụng một mở rộng của yêu cầu ủy quyền mở rộng (rich authorization request). Đó là một đặc tả. Và về cơ bản chúng ta có thể mô tả chính xác liệu người dùng có đang cấp sự đồng ý cho chúng hay không. Và điều đó được ghi lại trong quá trình cấp quyền truy cập. Trong một kịch bản thực tế, rất có thể máy chủ tài nguyên sẽ muốn xác minh điều đó. Nhưng vâng, [transcript bị gián đoạn]. Nhưng vâng, đó là thông báo đến. Vâng, nó trông như vậy. Vâng, đó là những gì nó trông giống như trên điện thoại của tôi khi tôi thực sự kết nối nó với mạng. Và tôi nhận được vô số thông báo.

Một trong những thách thức với yêu cầu ủy quyền mở rộng (rich authorization request) là đối tượng có thể tùy chỉnh tự do. Bạn có thể đặt bất cứ thứ gì bạn muốn. Và điều đó làm phức tạp việc hiển thị yêu cầu đó. Để giải quyết điều đó, chúng tôi đã tạo một lược đồ. Vì vậy, chúng tôi hỗ trợ một lược đồ đủ linh hoạt để cung cấp cho bạn mọi cơ hội để hiển thị bất cứ điều gì. Nhưng nó được biết đến và chúng tôi có thể giúp cho ứng dụng của chúng tôi trong trường hợp này, nhưng cũng trong các ứng dụng của bạn nếu bạn đang tự phát triển để hiển thị động điều này. Vì vậy, ứng dụng Guardian của chúng tôi có thể hiển thị bất kỳ chi tiết nào. Chúng tôi cung cấp lược đồ này cho bạn. Tuyệt vời. Tốt. Đúng vậy. Tuyệt vời.

Tính năng Ủy quyền Bất đồng bộ và Thử nghiệm

Vậy đó là một chút về các tính năng ủy quyền bất đồng bộ mới của chúng tôi. Phần cuối cùng và sau đó sẽ mở ra nhiều hơn cho thảo luận. Và vâng, tôi biết chúng ta sẽ có một chút thời gian. Nhưng tôi chỉ muốn nhanh chóng trình bày và thực hành với một số tích hợp đang được thử nghiệm. Điều này vẫn còn rất beta và được phát hành gần đây.

Trình diễn luồng DCR và triển khai công cụ

Vâng, đây là việc sử dụng luồng DCR (Đăng ký máy khách động). Tôi đang trình bày lại cách chúng tôi thực hiện với inspector, cũng như với Claude Code hoặc với OpenAPI App SDK (đối với Chat). Hiện tại tôi sẽ không thực hiện việc này vì không chắc có đủ thời gian, nhưng rõ ràng chúng ta có thể triển khai nó lên Vercel. Tôi đang sử dụng một Upstash database để xử lý state ở phía MCP server. Và vâng, bạn có thể chạy rất nhanh trên Vercel. Vì vậy, bạn có thể sử dụng tác nhân này và MCP server này để bắt đầu chia sẻ các công cụ này, mang công cụ của bạn đến bất cứ đâu.

Vì vậy, vâng, tôi sẽ trình bày, tôi đoán là tôi có một bản triển khai mà tôi đã đề cập trước đó. Tôi sẽ nhắm mục tiêu vào đó và thực hiện DCR với bản triển khai của mình. Trớ trêu thay, nó cũng được liên kết với cùng một identity provider (nhà cung cấp danh tính). Vì vậy, tôi sẽ nhận lại cùng một thông tin của mình, điều này thật tuyệt. Sau đó, tôi sẽ trình bày cách thức hoạt động của điều này trong Claude Code. Tôi sẽ bỏ qua ChatGPT App SDK. Có một tích hợp đang bắt đầu hoạt động ở đây. Cần có một số cấu hình, vì vậy hãy liên hệ nếu bạn cần điều này ngay hôm nay. Nhưng vâng, nó sẽ sẵn sàng trong tương lai rất gần. Chúng tôi hiện có một số tích hợp đã được thử nghiệm. Nhưng vâng, điều này cung cấp cho bạn cái nhìn tổng quan sơ bộ về cách bạn có thể nhanh chóng đưa các công cụ đó vào ChatGPT.

Kết nối với GPT và quản lý truy cập công cụ

Vâng, tôi sẽ nói lướt qua điều đó. Đây chỉ là tôi đang trình bày, như thể, "Ồ vâng, tôi đã kết nối nó trong GPT và tôi có thể truy cập các công cụ của mình ở đó." Vâng, hãy để tôi tiếp tục. Nếu bạn muốn nói chuyện với danh sách và nơi mà tôi sẽ trình bày cách lấy một client mới với phiên bản triển khai của mình và sau đó tích hợp nó vào Claude Code. Vâng, điều này chỉ để minh họa rằng client, MCP client, cũng nên chạy các chính sách tương tự hoặc các chính sách mà tất cả các client nên chạy là như nhau. Vì vậy, nên xác định, xác thực tôi và ủy quyền sự đánh giá cao, các chính sách ủy quyền tương tự nên xảy ra. Trong trường hợp này, chúng tôi đã nhúng MCP như một phần của máy chủ, nhưng trong trường hợp này, Patrick đã triển khai nó cho chúng tôi. Ngắt kết nối. Vì vậy, điều gì đó chúng tôi đã làm trước đây, trong trường hợp này, đây là một sản phẩm. Vâng, chính xác. Như bạn có thể thấy, nó đang yêu cầu ứng dụng của tôi và nó đã nhận được một mã truy cập với các phạm vi mà chúng tôi đã yêu cầu.

Sử dụng Claude Code và Thử thách Xác thực

Được rồi, vậy chúng ta sẽ khởi động Claude và vâng, chúng ta có thể đi sâu vào một phần nhỏ nếu bạn đã có MCP. Vâng, tôi có một lệnh trong README ở đây mà nó ở bản cuối cùng. Được rồi. Và sau đó, vâng, tôi cần thay thế mã thông báo. Tôi sẽ lưu một lần. Trong trường hợp này, tôi sẽ sử dụng mã thông báo của inspector của mình và Claude có hỗ trợ xác thực. Tuy nhiên, hiện tại có một vấn đề đang mở về việc chỉ định các phạm vi. Vì vậy, vâng, tôi sẽ chỉ sử dụng mã truy cập của inspector của mình. Nhưng vâng, bạn sẽ thấy điều đó với Claude và sau đó Claude vẫn sẽ khởi tạo. Hãy để tôi trình bày điều đó. Thật không may, đặc tả khá gọn gàng và tất cả các client đều triển khai theo cùng một cách. Vì vậy, vâng, tôi mong điều đó sẽ ổn định. Không có bản sao nào trong công cụ này. Không, được rồi. Được rồi. Một lần nữa, mã thông báo của tôi sẽ không khớp, đây là những giao dịch hư cấu. Được rồi. Được rồi. Ồ vâng. Giống như trước đây. Chúng ta sẽ bắt đầu hỏi về những gì chúng ta có trong một số khảo sát. Nó đã được kết nối chưa? Được rồi. Được rồi.

Có lẽ đôi khi tôi phải khởi động lại. Tôi không biết tại sao. Được rồi. Bây giờ hãy xem. Không. Hãy để tôi thử một cái nào đó ở đây. Cái đó không hoạt động. Vâng, tôi không thấy nó. Được rồi. Claude đã thêm. Vâng, có vẻ như nó ở đó. Hãy xem. Bạn có thể có thêm câu hỏi trong thời gian chờ đợi không? Vâng. Làm thế nào để tôi đặt câu hỏi trước đây? Tôi nghĩ tôi sẽ nhận được bản đánh giá khi bạn ở một nhà hàng không phải là số không. Có lẽ ngữ cảnh ở đây là mọi thứ trong đó. Hoặc giả sử bạn là người tiêu dùng hoặc thứ gì đó. Có lẽ toàn bộ luồng này sẽ là trường hợp đó. Nghĩ rằng nếu bạn đang sử dụng Opta 10, bạn đang sử dụng Opta trong không gian làm việc của mình. Hai thứ đó hoạt động cùng nhau như thế nào? Hoặc liệu thứ này cũng sẽ có sẵn trên trang web của Opta?

Mô hình chính sách và quyền truy cập của tác nhân

Không. Tôi nghĩ ý tưởng đó đã gọi cho tôi, tôi sẽ không biết chính xác. Vì vậy, 100%. Nhưng điều tôi nghĩ là chúng ta sẽ tạo ra một kiểu cầu nối nào đó. Bạn có thể áp dụng các chính sách tương tự như Opta với tư cách là một nhân viên cho các tác nhân. Và hạn chế quyền truy cập vào các dịch vụ đó như bạn sẽ làm với 7.0. Đó là nơi tôi bắt đầu câu hỏi của bạn, Marles. Một kiểu như ở đây. Vâng. Vậy thì khái niệm này hoạt động cùng nhau như thế nào? Bởi vì nó có vẻ như là một tính năng của Ontino, một trong những thứ đó. Đúng vậy. Những gì có trên Opta của tôi? Vâng, đúng vậy. Nó là một phần riêng biệt. Nhưng theo như tôi biết, chúng tôi làm việc cùng nhau trên các sản phẩm. Nhưng vâng, chúng ta có thể kết nối sau nếu bạn muốn. Tôi có thể tìm hiểu thêm. Vâng, rất có thể là vậy. Đó là điều tôi đang làm ở đây. Bạn có cần chạy lệnh Claude này không? Bạn không phải chạy nó bên ngoài phiên Claude sao? Có lẽ. Tôi không biết. Ồ, trong terminal. Được rồi. Vâng, hãy thử điều đó. Còn gì nữa không?

Ưu điểm của định danh tác nhân và quản lý mã thông báo

Vâng. Có vẻ như nếu tôi muốn chỉ vào tác nhân, một cách tôi có thể bắt đầu là chỉ cần sử dụng croquet của người dùng thay mặt cho tác nhân như chính tác nhân đó. Vậy bạn cảm thấy lợi thế của điều này là gì? Định danh tác nhân? Bạn có những tính năng gì? Vì vậy, khi bạn nói tôi có thể chỉ cần chuyển hoặc bạn xác thực người dùng và chuyển tiếp mã truy cập đến tác nhân bằng cách nào đó hoặc đó là điều đó. Xin đừng làm điều đó. Vì vậy, mã truy cập được dùng để chuyển. Nó sẽ mang tính chuyên sâu về khả năng vận hành. Nó sẽ cồng kềnh vì mã truy cập cuối cùng sẽ hết hạn. Vì vậy, tại một thời điểm nào đó, bạn sẽ cần liên hệ lại với người dùng. Được rồi, đăng nhập và thực hiện lại toàn bộ quá trình. Vậy tác nhân của bạn sẽ tự chủ đến mức nào trong kịch bản đó?

Đó là điều chúng tôi cố gắng giải quyết. Vì vậy, chúng tôi thiết lập kết nối đó, mối quan hệ đó và chúng tôi chịu trách nhiệm về phần phức tạp, khó chịu này của việc làm mới mã thông báo, lưu trữ mã thông báo. Và vâng, tất cả các bước tăng phạm vi. Được rồi, cuối cùng cũng hoạt động ở đây. Tôi nghĩ đó là một số tương tác tôi có thể thực hiện với tác nhân hoặc có thể lưu trợ lý trò chuyện. Và vì vậy, bất cứ khi nào tác nhân thực hiện hành động, tôi không nhất thiết phải làm vậy. Đối với một số ví dụ chúng ta đã nói trước đây, hãy tưởng tượng một kiểu task runner nào đó. Đăng nhập, bạn có định danh, bạn có một loại dashboard truyền thống nơi bạn liệt kê các ứng dụng có thể kết nối của mình, Slack, Gmail, Google Calendar, bất cứ thứ gì. Và họ chỉ sử dụng nó một lần. Vì vậy, một khi những thứ này được kết nối, bạn sẽ cấp cho client tác nhân quyền truy cập vào các ứng dụng đó. Mỗi lần, vì vậy người dùng lần sau kết nối với cuộc trò chuyện, thế là xong. Bạn không cần phải chạy lại tất cả những thứ này. Nó đã được thực hiện rồi. Mối quan hệ đã được thiết lập rồi. Vì vậy, người dùng sẽ mở lại cuộc trò chuyện. Bạn không cần phải thực hiện tất cả các màn hình kết nối phạm vi, lời nhắc, đồng ý này. Thế là xong. Tất cả. Cuối cùng có thể chết. Tùy thuộc vào chính sách của hệ thống phía trên của bạn. Vì vậy, các mã thông báo đầu tiên có thể hết hạn và trong trường hợp đó, vâng, bạn sẽ cần xử lý tất cả. Bạn cần tải lại. Bạn làm điều đó một lần.

Tùy chọn triển khai và khả năng mở rộng

Vâng, chỉ là một bản cập nhật, cuối cùng cũng có thể gửi văn bản hoặc phiên bản Claude của tôi, tôi đoán vậy. Nhưng vâng, tôi đã có thể xác thực và trình bày. Chúng tôi đã trải qua màn hình xác thực và vâng, bây giờ tôi có thể truy cập các công cụ tương tự của mình trong một phiên bản triển khai. Bạn có thể làm điều này với một số nhà cung cấp ngay bây giờ, phải không? Tất cả những nhà cung cấp nào hỗ trợ DCR như Carlos đã nói, giống như bất kỳ nhà cung cấp nào hỗ trợ DCR, client tĩnh hoặc client được cấu hình sẵn. Và sau đó, vâng, metadata ID client sẽ sớm là đặc tả tiếp theo mà tôi tin rằng sẽ được triển khai. Vì vậy, vâng, bạn sẽ có rất nhiều lựa chọn để đăng ký client mới, tác nhân mới và truy cập các công cụ của bạn. Vâng, tôi không biết liệu có bất cứ điều gì khác để quay lại. Các câu hỏi. Được rồi. Tôi nghĩ vậy là đủ. Các câu hỏi và phản hồi, xin vui lòng liên hệ hoặc. Vâng, vâng. Tôi ở đây để, như nghiên cứu tôi đã trình bày cho câu hỏi của anh ấy, có một nhánh mới hơn không? Vâng. Vâng, chắc chắn rồi. Và hãy để tôi đẩy điều đó vào kho lưu trữ của anh ấy và hãy để tôi trình bày trạng thái cuối cùng của tôi bây giờ. Và vâng, tôi sẽ kéo nó lên và liên kết nó ở đây. Ngoài ra, vâng. Vâng, lần đầu tiên với bản phát hành chính trong tuần này, giống như, chúng tôi vừa xuất bản bản này khoảng hai ngày trước. Vì vậy, vâng.

Trạng thái cuối cùng của dự án và các thay đổi được áp dụng

Được rồi, được rồi. Nhưng vâng, trạng thái cuối cùng nằm trong nhánh của tôi ở đây, finish state. Và điều đó sẽ có tất cả các thay đổi được áp dụng. Và tôi nghĩ tôi đã điều chỉnh một trong các công cụ lịch sử đơn hàng, nhưng nó khá đơn giản. Có một số công cụ khác được triển khai ở đó, nhưng vâng, tùy thuộc vào bạn. Bạn muốn triển khai gì ở đó. Nhưng vâng, tôi có thể, hãy xem, tôi không biết liệu tôi có thể, tôi có thể liên kết điều này trong ghi chú sau. Vâng. Và chúng tôi sẽ đảm bảo rằng bạn có điều này. Tôi có lẽ thực sự sẽ đẩy nó lên nhánh workshop upstream của chúng tôi. Và vâng, một lời từ chối trách nhiệm nhỏ, thanh ảo (virtual bar) có thể gặp phải một số gián đoạn khi chúng tôi phát triển thêm nhiều thứ. Vì vậy, vâng, cảm ơn bạn. Được rồi. Cảm ơn bạn. Tuyệt vời. Cảm ơn bạn.