[{"data":1,"prerenderedAt":71},["ShallowReactive",2],{"legacy:insights\u002Fai-agent-data-permission:en":3},{"id":4,"title":5,"description":6,"keywords":7,"author":8,"robots":9,"bodyClass":10,"image":11,"jsonld":12,"html":70},"insights\u002Fai-agent-data-permission","Who can ask which numbers? Keep permissions anchored to the data row - JEDP Digital Platform","智能体问数不是新开一个数据出口。运行态智能体按列表页发布时配的权限组裁行裁列——适用人员、数据范围、字段权限与列表页同源，越权请求应被拒绝并留痕。本文说明权限组判定、导出与办理的风险分级、落地顺序与六项验收。","AI 问数,行级权限,智能体 权限控制,数据权限 制造业","Shenzhen Langbowan Information Technology Co., Ltd.","index, follow","page-insights","https:\u002F\u002Fwww.jedp.cn\u002Fres\u002Fimages\u002Fproduct\u002Fplatform-overview.webp",[13,30,44],{"@context":14,"@type":15,"@id":16,"headline":17,"description":6,"inLanguage":18,"datePublished":19,"dateModified":19,"articleSection":20,"keywords":21,"image":11,"author":22,"publisher":24,"isPartOf":25,"mainEntityOfPage":27},"https:\u002F\u002Fschema.org","Article","https:\u002F\u002Fwww.jedp.cn\u002Finsights\u002Fai-agent-data-permission#article","Who can ask which numbers? Keep permissions anchored to the data row","zh-CN","2026-10-23","SaaS · AI agents","AI 问数, 行级权限, 智能体 权限控制, 数据权限 制造业",{"@id":23},"https:\u002F\u002Fwww.jedp.cn\u002F#organization",{"@id":23},{"@id":26},"https:\u002F\u002Fwww.jedp.cn\u002Finsights#collection",{"@type":28,"@id":29},"WebPage","https:\u002F\u002Fwww.jedp.cn\u002Finsights\u002Fai-agent-data-permission",{"@context":14,"@type":31,"itemListElement":32},"BreadcrumbList",[33,38,42],{"@type":34,"position":35,"name":36,"item":37},"ListItem",1,"Home","https:\u002F\u002Fwww.jedp.cn\u002F",{"@type":34,"position":39,"name":40,"item":41},2,"Insights","https:\u002F\u002Fwww.jedp.cn\u002Finsights",{"@type":34,"position":43,"name":17,"item":29},3,{"@context":14,"@type":45,"@id":46,"mainEntity":47},"FAQPage","https:\u002F\u002Fwww.jedp.cn\u002Finsights\u002Fai-agent-data-permission#faq",[48,54,58,62,66],{"@type":49,"name":50,"acceptedAnswer":51},"Question","Can an agent bypass existing permissions?",{"@type":52,"text":53},"Answer","It should not, and cannot. Runtime queries trim rows and columns by the permission groups the current user hits - applicable people, data scope and field permissions share the same source as the list page, with no second set; out-of-scope requests should be rejected and logged. If an agent product asks you to configure a separate set of data permissions just for AI, it has already split the permission system in two, and audits will never reconcile.",{"@type":49,"name":55,"acceptedAnswer":56},"Can Q&A see company-wide data?",{"@type":52,"text":57},"It depends on the person's data scope, not on whether they know how to use AI. A department manager typically sees their own department and its subordinates; only a group-level analyst gets a cross-organization view. Selling “it can query the whole company” as a feature is turning overreach into a capability.",{"@type":49,"name":59,"acceptedAnswer":60},"Can the agent modify data rows directly?",{"@type":52,"text":61},"Writes go through platform business APIs, under the same function permissions and flow-node constraints, and never on someone else's behalf. An agent that writes straight to the database looks convenient; the price is that validation, the approval chain and the audit trail all disappear.",{"@type":49,"name":63,"acceptedAnswer":64},"Why is export riskier than query?",{"@type":52,"text":65},"Query results stay inside the system; exports take data out. Exports should limit field scope, record frequency and destination, and carry a watermark; for payroll, cost and customer pricing, bulk export should be off by default.",{"@type":49,"name":67,"acceptedAnswer":68},"Our permissions are already messy — can we still do AI data Q&A?",{"@type":52,"text":69},"Freeze the permission matrix and metric definitions first, then open Q&A. Launching an agent on messy permissions compresses data that used to take several clicks into a single sentence; the risk grows rather than shrinks.","\u003Carticle class=\"insight-article\">\n    \u003Cdiv class=\"insight-container\">\n      \u003Cnav class=\"breadcrumb\" aria-label=\"Breadcrumb\">\n        \u003Ca href=\"\u002F\">Home\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Ca href=\"\u002Finsights\">Insights\u003C\u002Fa>\n        \u003Cspan class=\"breadcrumb-sep\">\u002F\u003C\u002Fspan>\n        \u003Cspan>SaaS · AI agents\u003C\u002Fspan>\n      \u003C\u002Fnav>\n\n      \u003Cheader class=\"insight-hero\">\n        \u003Cdiv class=\"insight-tags\">\u003Cspan class=\"r-tag\">AI data Q&A\u003C\u002Fspan>\u003Cspan class=\"r-tag\">Row-level permissions\u003C\u002Fspan>\u003Cspan class=\"r-tag\">Audit trail for overreach\u003C\u002Fspan>\u003C\u002Fdiv>\n        \u003Ch1>Who can ask which numbers? Keep permissions anchored to the data row\u003C\u002Fh1>\n        \u003Cp class=\"insight-lede\">“Pull this year's gross margin for South China.” One line in a chat box, but a cross-department data pull inside the permission system. What goes wrong with AI data Q&A is rarely a wrong number; it is a correct number for data you were never supposed to see.\u003C\u002Fp>\n        \u003Cdiv class=\"insight-meta\">\n          \u003Cspan>Updated 2026-10-23\u003C\u002Fspan>\n          \u003Cspan class=\"dot\" aria-hidden=\"true\">\u003C\u002Fspan>\n          \u003Cspan>~11 min read\u003C\u002Fspan>\n          \u003Cspan class=\"dot\" aria-hidden=\"true\">\u003C\u002Fspan>\n          \u003Cspan>Manufacturing digitalization · SaaS · AI agents\u003C\u002Fspan>\n        \u003C\u002Fdiv>\n      \u003C\u002Fheader>\n      \u003Csection class=\"insight-takeaways\">\n        \u003Ch2>What you'll take away\u003C\u002Fh2>\n        \u003Cul>\u003Cli>AI data Q&A is not a new data exit: permissions must reuse the platform's existing authorization, never a separate “AI-only” allowlist\u003C\u002Fli>\u003Cli>The unit that governs which numbers can be asked for is the permission group: applicable people, data scope and field permissions are configured together, and the agent trims rows and columns by them instead of keeping a set of its own\u003C\u002Fli>\u003Cli>Deny unauthorized requests on the spot and log them; a rejected request is the cheapest permission health check you will ever run\u003C\u002Fli>\u003Cli>Export and transaction are far riskier than a quick look: exports need watermarking and rate caps, transactions must go through business APIs and the original approver\u003C\u002Fli>\u003Cli>Reverse the usual rollout order: freeze metric definitions and the permission matrix first, then widen query scope, and only then open write operations\u003C\u002Fli>\u003C\u002Ful>\n      \u003C\u002Fsection>\n\n      \u003Cdiv class=\"insight-layout\">\n        \u003Cdiv class=\"insight-body\">\n\u003Ch2 id=\"一句-帮我查一下-跨了三个部门\">One “just look it up” request crosses three departments\u003C\u002Fh2>\n\u003Cp>Monday morning, a sales director types one line: pull H1 gross margin for South China, broken down by customer. Three seconds later a chart appears and the top five customers are obvious.\u003C\u002Fp>\n\u003Cp>What has to happen behind that line? The system must map “South China” to the right sales organizations and shipping plants; know which definition of gross margin is in force, freight included or not, rebates treated as cost or not; and know whether the person asking may see customer-level price and cost. Get any of the first three wrong and you get no chart, or a wrong one.\u003C\u002Fp>\n\u003Cp>The fourth question is where things usually break: should this person see these customers' prices at all?\u003C\u002Fp>\n\u003Cp>AI data Q&A made data access easier, and it made overreach easier too. Overreach used to require knowing which menu to open, which export to click, whose approval to route around. Now it only requires phrasing the question politely. So the real design question at launch is not how much it can answer, but who may ask what.\u003C\u002Fp>\n\u003Ch2 id=\"智能体不是新开一个数据出口\">An agent is not a new data exit\u003C\u002Fh2>\n\u003Cp>The first instinct in most companies is to give the agent its own data source account. It looks convenient, but it opens a read-only back door for the whole company: the agent connects with a high-privilege account, and everyone who asks borrows that account.\u003C\u002Fp>\n\u003Cp>The problem is that the account's privileges have nothing to do with the person asking. A warehouse clerk asks for last month's raw material cost and gets an answer, because the agent is connected as that high-privilege account. Systems like this demo beautifully and fail every audit: the log shows only “the agent”.\u003C\u002Fp>\n\u003Cp>Do the opposite: the agent holds no data privileges of its own. It inherits the signed-in user's permission context. Who the user is, which department, which position, which data rows are visible — all fixed the moment the request arrives. The agent only organizes queries, generates charts and states definitions inside that boundary.\u003C\u002Fp>\n\u003Cp>There is a simple test for whether a product works this way: move one person from department A to department B, then ask the same question the next day. If the answer changes, permissions are real. If it does not, permissions are decoration.\u003C\u002Fp>\n\u003Cp>JEDP's dual agents are built exactly this way: the design-time agent models in natural language and publishes through the designer; the runtime agent queries within the person's authorized scope, can output chat text and images, export to Office, HTML or Markdown, and create documents or run approvals through platform business APIs. It never writes to the database directly, and its data scope never exceeds the permission groups the current account hits on the corresponding list page.\u003C\u002Fp>\n\u003Ch2 id=\"权限组决定智能体能查到哪些行\">Permission groups decide which rows the agent can reach\u003C\u002Fh2>\n\u003Cp>A platform list really has two gates: the on-page filters are packaged by the front end, while the\u003Cstrong>permission groups\u003C\u002Fstrong>configured at publish time are enforced by the server. The query agent honours only the second gate - it cannot obtain the front-end filter package, and should not. What actually decides which numbers the agent can reach is the permission groups, not the model's good intentions.\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>What a permission group configures\u003C\u002Fth>\u003Cth>What it decides\u003C\u002Fth>\u003Cth>Typical cost of getting it wrong\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Applicable people\u003C\u002Ftd>\u003Ctd>Who the group applies to, with an exclusion list\u003C\u002Ftd>\u003Ctd>External organizations left out, so a supplier sees internal prices\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Data Range\u003C\u002Ftd>\u003Ctd>Own records \u002F custom conditions \u002F unrestricted\u003C\u002Ftd>\u003Ctd>Meant for one department but set to unrestricted, pulling in the whole group\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Field permissions\u003C\u002Ftd>\u003Ctd>Which columns are visible, read-only or hidden\u003C\u002Ftd>\u003Ctd>Cost price hidden on the list still comes back through the agent\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>When a person hits several groups their scopes are unioned; if they hit none, or the list page has no permission group at all, it falls back to\u003Cstrong>own records\u003C\u002Fstrong> - the strictest tier, not the loosest. And own records covers more than what I created: it also includes documents where I am a pending or completed approver, or a CC or forward recipient. That is exactly how the platform list counts, and the agent must match it, otherwise users instantly notice that the list has rows the agent cannot find.\u003C\u002Fp>\n\u003Cp>The question a user types may not name a list page. The system looks it up by list name first, then by the underlying form table, working down level by level; if nothing is found it still falls back to own records. Whichever path is taken, there is only one hard rule:\u003Cstrong>for the same logged-in person, the rows the agent can see must be a subset of the rows that person can see on the corresponding list page\u003C\u002Fstrong> - stricter is fine, wider is not.\u003C\u002Fp>\n\u003Cp>Field permissions go wrong even more easily:\u003Cstrong>hiding a column is not the same as making it unaskable\u003C\u002Fstrong>. Hide the cost price column on a list, and if it is only hidden in the page while the execution layer still returns the column, a user just rephrases - 'list the purchase unit price for this item' - and the data comes out anyway. Hiding is presentation; trimming the column is permission.\u003C\u002Fp>\n\u003Ch2 id=\"越权要当场拒绝-而且要留痕\">Deny on the spot, and log it\u003C\u002Fh2>\n\u003Cp>“Let it answer first, sort out permissions later” is the most dangerous sentence in AI data Q&A. The temptation is real: the data is already in the database, the model already read it, withholding it feels wasteful.\u003C\u002Fp>\n\u003Cp>But a denial has value. When someone asks for South China customer margin while holding only East China scope, the system should say plainly: your data scope is East China, so South China customer detail cannot be returned. That sentence does three things at once — states the boundary, keeps the user from reading it as a system fault, and leaves an auditable record.\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Request\u003C\u002Fth>\u003Cth>disposal\u003C\u002Fth>\u003Cth>Explanation\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Beyond organizational scope\u003C\u002Ftd>\u003Ctd>Deny and state the boundary\u003C\u002Ftd>\u003Ctd>Tell the user what is queryable; return no rows\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Beyond field permission\u003C\u002Ftd>\u003Ctd>Deny that field, return the rest\u003C\u002Ftd>\u003Ctd>Never mask silently, so users do not mistake it for missing data\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Act on someone else's behalf\u003C\u002Ftd>\u003Ctd>Deny\u003C\u002Ftd>\u003Ctd>The approver must be the person resolved by the flow node\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>High-frequency bulk pulls\u003C\u002Ftd>\u003Ctd>Rate-limit and alert\u003C\u002Ftd>\u003Ctd>Normal analysis does not need dozens of exports a minute\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Suspected probing in combination\u003C\u002Ftd>\u003Ctd>Log and review\u003C\u002Ftd>\u003Ctd>Each question is compliant; together they are overreach, visible only in behavior\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>The last row deserves a note. Real overreach rarely takes everything at once; it takes ten slices and assembles them. Every single log line is compliant, and only the sequence of questions from one account reveals intent. So query logs must aggregate by person, by time and by metric, not just record that someone asked something.\u003C\u002Fp>\n\u003Ch2 id=\"导出与办理-比-看一眼-危险得多\">Export and transaction: far riskier than a quick look\u003C\u002Fh2>\n\u003Cp>Querying and exporting are not the same risk level. Query results stay inside the system; an export carries data outside, and one export can equal one data leak.\u003C\u002Fp>\n\u003Cp>Exports need at least three controls: field scope (sensitive fields excluded from export templates by default), volume and frequency (approval or a hard no above a threshold), and traceability (watermarked files, attributable to a person). For payroll, cost and negotiated customer pricing, default to summaries only, never line detail.\u003C\u002Fp>\n\u003Cp>Write operations raise the risk another level. “Close this nonconformance report for me” sounds like an efficiency win; in practice it bypasses the approval chain. The compliant pattern: the agent may initiate, prefill and point out missing fields, but submission must go through the business API and land on the original flow node, handled by that node's approver. The agent never approves on someone else's behalf. No exceptions.\u003C\u002Fp>\n\u003Ch2 id=\"权限从哪来-别在智能体里另建一套\">Where permissions come from: do not build a second set inside the agent\u003C\u002Fh2>\n\u003Cp>If the agent maintains its own “who may ask what” configuration, it will eventually diverge from the main permission system. The consequence is not an error but a gap where both sides assume the other is enforcing: business believes the agent is restricted, IT believes the main system is restricted, and the middle is empty.\u003C\u002Fp>\n\u003Cp>Authorization should have exactly one source. When someone joins, transfers, takes a concurrent post or leaves, the permission changes once in the main system and the agent follows automatically. Permission groups are configured once when the list page is published - applicable people, data scope and field permissions all live there; the org engine supplies the department tree, positions and reporting lines for conditions to reference; the agent is only a consumer.\u003C\u002Fp>\n\u003Cp>Two details decide whether this survives long term. First, \u003Cstrong>authorization switches on the position's effective date\u003C\u002Fstrong> — concurrent posts, secondments and delegation must be modeled explicitly with an expiry date, otherwise “leave it open for convenience” becomes permanent excess privilege. Second, \u003Cstrong>Reclaim\u003C\u002Fstrong>recall: revoking access at resignation, transfer or project close needs an owner and a deadline. Permission debt does not disappear; it accumulates until an audit.\u003C\u002Fp>\n\u003Ch2 id=\"开放顺序-先冻口径-再放范围-最后开写\">Rollout order: freeze definitions, then scope, then writes\u003C\u002Fh2>\n\u003Cp>Many projects open the widest possible query scope at launch, on the grounds of letting people feel the value first. That order is exactly the most dangerous one.\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Stage\u003C\u002Fth>\u003Cth>What opens\u003C\u002Fth>\u003Cth>Completion mark\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\u003Ctr>\u003Ctd>Step one\u003C\u002Ftd>\u003Ctd>Freeze metric definitions and the permission matrix\u003C\u002Ftd>\u003Ctd>a single metric definition; every list page's permission groups can be drawn as a matrix\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Step Two\u003C\u002Ftd>\u003Ctd>Open read-only Q&A, limited to two or three domains\u003C\u002Ftd>\u003Ctd>Unauthorized requests are correctly denied and logged; definitions ship with the answer\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Step Three\u003C\u002Ftd>\u003Ctd>Open exports, limited by field and frequency\u003C\u002Ftd>\u003Ctd>Exports are attributable to a person; sensitive domains have no bulk export by default\u003C\u002Ftd>\u003C\u002Ftr>\u003Ctr>\u003Ctd>Step Four\u003C\u002Ftd>\u003Ctd>Open write operations through business APIs\u003C\u002Ftd>\u003Ctd>Documents are handled at flow nodes; the approver cannot be substituted\u003C\u002Ftd>\u003C\u002Ftr>\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>A clear completion signal at each step beats a launch date. Step one especially: open Q&A before definitions are frozen and you get three different gross margins, and the model amplifies the mess because it answers fast and with confidence.\u003C\u002Fp>\n\u003Ch2 id=\"六项验收-能演示才算做到\">Six acceptance tests: if you cannot demo it, it is not done\u003C\u002Fh2>\n\u003Cp>Permission design loves to stop at the slide. Do not review architecture diagrams; ask for these six actions to be performed live.\u003C\u002Fp>\n\u003Col>\u003Cli>Ask for department B data from a department A account: explicit denial, scope stated\u003C\u002Fli>\u003Cli>Ask from the same account for a sensitive column beyond field permission: only that column denied, the rest returned\u003C\u002Fli>\u003Cli>Switch to a view-only account and try to initiate a document: denied\u003C\u002Fli>\u003Cli>Move the account from department A to B: the next day the same question returns a different scope\u003C\u002Fli>\u003Cli>Export twenty times in quick succession: rate limit or approval triggered\u003C\u002Fli>\u003Cli>Open one overreach record: who, when, what was asked, which rule denied it\u003C\u002Fli>\u003C\u002Fol>\n\u003Cp>All six demonstrable, and permissions live in the system. Any one missing means that part is still policy on paper.\u003C\u002Fp>\n\u003Ch2 id=\"什么情况下先别上\">When not to start\u003C\u002Fh2>\n\u003Cp>Finally, the boundaries. In three situations I would build the foundation first and hold off on opening data Q&A.\u003C\u002Fp>\n\u003Cp>First, the permission matrix itself is a mess — roles copied person by person, data scope held together by convention, departed accounts never disabled. Adding an agent here compresses data that used to take several clicks into a single sentence, magnifying the risk instead of containing it.\u003C\u002Fp>\n\u003Cp>Second, metric definitions still change every week. The model will justify every version persuasively, and users will treat it as the conclusion.\u003C\u002Fp>\n\u003Cp>Third, master data has no uniqueness — one customer with three records, one material with two codes. Aggregation counts one thing as two, and nothing shows it.\u003C\u002Fp>\n\u003Cp>None of these is an AI problem; AI just exposes them faster. Conversely, with these three in place the efficiency gain is real: no waiting for someone to export a spreadsheet, no half-hour meeting for one number, and the definition arrives with the answer.\u003C\u002Fp>\n\u003Cul>\u003Cli>Dual agents: the capability boundary between design-time and runtime\u003C\u002Fli>\u003Cli>Permission engine: row- and field-level authorization\u003C\u002Fli>\u003Cli>Organization engine: people-centric organization master data\u003C\u002Fli>\u003Cli>Multi-tenant and organizational isolation decision table\u003C\u002Fli>\u003Cli>Why design-time and runtime must be separate\u003C\u002Fli>\u003C\u002Ful>\n        \u003C\u002Fdiv>\n        \u003Caside class=\"insight-toc\" aria-label=\"On this page\">\n          \u003Ch2>Contents\u003C\u002Fh2>\n          \u003Ca class=\"h2\" href=\"#一句-帮我查一下-跨了三个部门\">One “just look it up” request crosses three departments\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#智能体不是新开一个数据出口\">An agent is not a new data exit\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#权限组决定智能体能查到哪些行\">Permission groups decide which rows the agent can reach\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#越权要当场拒绝-而且要留痕\">Deny on the spot, and log it\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#导出与办理-比-看一眼-危险得多\">Export and transaction: far riskier than a quick look\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#权限从哪来-别在智能体里另建一套\">Where permissions come from: do not build a second set inside the agent\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#开放顺序-先冻口径-再放范围-最后开写\">Rollout order: freeze definitions, then scope, then writes\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#六项验收-能演示才算做到\">Six acceptance tests: if you cannot demo it, it is not done\u003C\u002Fa>\n          \u003Ca class=\"h2\" href=\"#什么情况下先别上\">When not to start\u003C\u002Fa>\n        \u003C\u002Faside>\n      \u003C\u002Fdiv>\n\n      \u003Cdiv class=\"insight-cta\">\n        \u003Cp>\u003Cstrong>Want to apply this in your plant?\u003C\u002Fstrong>Resources has matching self-assessments and templates—or book a live demo.\u003C\u002Fp>\n        \u003Cdiv class=\"insight-cta-actions\">\n          \u003Ca href=\"\u002Fresources?from=agent#selftest\" class=\"btn btn-outline\">Self-assessment in Resources\u003C\u002Fa>\n          \u003Ca href=\"\u002Fcases#case-platform\" class=\"btn btn-outline\">Platform acceptance case\u003C\u002Fa>\n          \u003Ca href=\"\u002Fcontact?from=agent\" class=\"btn\">Get a demo\u003C\u002Fa>\n        \u003C!-- next-step:BEGIN -->\u003Ca class=\"btn\" href=\"\u002Fengines\">Product solution: \u003Cspan>Platform\u003C\u002Fspan>\u003C\u002Fa>\u003Ca class=\"btn btn-outline\" href=\"\u002Fres\u002Fresources\u002Fkits\u002F17-platform-overseas-multitenant.html\">Matching resource kit: \u003Cspan>Readiness for Going Abroad Self-Assessment   Multi-Tenant Decision Table\u003C\u002Fspan>\u003C\u002Fa>\u003C!-- next-step:END -->\n        \u003C\u002Fdiv>\n      \u003C\u002Fdiv>\n      \u003Csection class=\"insight-faq\" id=\"faq\">\n        \u003Ch2>FAQ\u003C\u002Fh2>\n        \u003Cp class=\"insight-faq-sub\">Quick answers on this topic—still stuck?\u003Ca href=\"\u002Fcontact?from=agent\">Contact\u003C\u002Fa>\u003C\u002Fp>\n        \u003Cdiv class=\"faq-list\">\n        \u003Cdetails class=\"faq-item\" open>\n          \u003Csummary>Can an agent bypass existing permissions?\u003C\u002Fsummary>\n          \u003Cp>It should not, and cannot. Runtime queries trim rows and columns by the permission groups the current user hits - applicable people, data scope and field permissions share the same source as the list page, with no second set; out-of-scope requests should be rejected and logged. If an agent product asks you to configure a separate set of data permissions just for AI, it has already split the permission system in two, and audits will never reconcile.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Can Q&A see company-wide data?\u003C\u002Fsummary>\n          \u003Cp>It depends on the person's data scope, not on whether they know how to use AI. A department manager typically sees their own department and its subordinates; only a group-level analyst gets a cross-organization view. Selling “it can query the whole company” as a feature is turning overreach into a capability.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Can the agent modify data rows directly?\u003C\u002Fsummary>\n          \u003Cp>Writes go through platform business APIs, under the same function permissions and flow-node constraints, and never on someone else's behalf. An agent that writes straight to the database looks convenient; the price is that validation, the approval chain and the audit trail all disappear.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Why is export riskier than query?\u003C\u002Fsummary>\n          \u003Cp>Query results stay inside the system; exports take data out. Exports should limit field scope, record frequency and destination, and carry a watermark; for payroll, cost and customer pricing, bulk export should be off by default.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003Cdetails class=\"faq-item\">\n          \u003Csummary>Our permissions are already messy — can we still do AI data Q&A?\u003C\u002Fsummary>\n          \u003Cp>Freeze the permission matrix and metric definitions first, then open Q&A. Launching an agent on messy permissions compresses data that used to take several clicks into a single sentence; the risk grows rather than shrinks.\u003C\u002Fp>\n        \u003C\u002Fdetails>\n        \u003C\u002Fdiv>\n      \u003C\u002Fsection>\n      \u003Csection class=\"insight-related\">\n        \u003Ch2>Related reading\u003C\u002Fh2>\n        \u003Cdiv class=\"insight-related-grid\">\n          \u003Carticle class=\"r-card\">\n            \u003Cdiv class=\"r-tags\">SaaS · AI agents\u003C\u002Fdiv>\n            \u003Ch3>Where AI should enter enterprise systems: keep design-time and runtime agents separate\u003C\u002Fh3>\n            \u003Cp>Enterprise AI fails mostly on unclear ownership. Starting from the “one chat window does everything” pattern, it explains the asymmetric cost of building systems versus judging the business, why design and runtime need separate entrances, human-in-the-loop and traceability.\u003C\u002Fp>\n            \u003Cdiv class=\"r-meta\">2026-09-17 · ~9 min\u003C\u002Fdiv>\n          \u003C\u002Farticle>\n          \u003Carticle class=\"r-card\">\n            \u003Cdiv class=\"r-tags\">SaaS · AI agents\u003C\u002Fdiv>\n            \u003Ch3>Four hard problems in enterprise AI: the pilot succeeds, the rollout stalls\u003C\u002Fh3>\n            \u003Cp>Enterprise AI stalls at four hurdles: scattered data, no domain knowledge, no landing path, no way to measure. Each gets a self-check question you can run today and a sequencing rule, so you know when to wait instead of asking for data.\u003C\u002Fp>\n            \u003Cdiv class=\"r-meta\">2026-10-15 · about 13 min\u003C\u002Fdiv>\n          \u003C\u002Farticle>\n          \u003Carticle class=\"r-card\">\n            \u003Cdiv class=\"r-tags\">Insights\u003C\u002Fdiv>\n            \u003Ch3>Choosing a digital foundation: set the yardstick with these 8 questions before talking price\u003C\u002Fh3>\n            \u003Cp>When choosing a digital foundation, set the yardstick before discussing price. Eight verifiable questions cover modeling limits, process engine, data ownership, extension boundaries, multi-organization and multi-tenant, internationalization and implementation capability.\u003C\u002Fp>\n            \u003Cdiv class=\"r-meta\">2026-08-13 · ~9 min\u003C\u002Fdiv>\n          \u003C\u002Farticle>\n        \u003C\u002Fdiv>\n      \u003C\u002Fsection>\n    \u003C\u002Fdiv>\n  \u003C\u002Farticle>",1793937990856]