NewCore 把 AI agent 變成可管身份

NewCore 的做法是把 AI agent 變成可管理的身份，能授權、審核，也能撤銷。

我盯身份系統跟 AI 工具的交集一陣子了，越看越煩。人還沒管好，先把 service account、共享 API key、暫時性憑證全塞進來，然後大家還假裝這叫流程。真正讓我不舒服的不是複雜，是那種「先上線再說」的習慣：每多一個 agent，就多一個例外；每多一個例外，就多一筆安全債。最後出事時，沒人知道到底誰能碰什麼。

NewCore 這套東西有意思的地方，不是又做一個 AI 外殼，也不是做一個看起來很忙的 dashboard。它是在碰真正的身份底層：讓軟體工作者有自己的身份、權限、生命週期，還能被撤掉。這件事如果真的成形，身份管理就不再只是後台雜務，而是 agent 時代的控制平面。

我這次是從 TechCrunch 的 Jagmeet Singh 這篇文章切進去的，然後把它拆成我自己會怎麼寫產品規格、怎麼做 access review、怎麼設 revoke 路徑。

文中提到，NewCore 以 6600 萬美元浮出檯面，領投是 Cyberstarts，Index Ventures 和 Evolution Equity Partners 也有參與。它的主張很直接：如果 agent 要坐進公司工作流，那它就得像員工一樣有身份、權限、生命週期和撤權機制。

別再把 agent 當成高級 service account

“AI agents should be treated as first-class identities with their own permissions, life cycle controls, and revocation mechanisms, rather than as traditional service accounts or machine credentials.”

翻譯一下就是：別再把 agent 塞進 backend job 那個舊籃子裡了。那個籃子本來就已經塞爆，拿來放 cron、CI、機器對機器 token 還行；但 agent 不是單純跑一次就停，它會分支、重試、呼叫工具、持續操作。你用舊模型硬套，最後一定是誰都說不清楚。

我看過一個很典型的失敗案例：團隊先讓 coding agent 用某個人的 token，覺得「先試試看」。一開始很順，兩週後 token 藏在哪裡沒人記得，另一組人照抄做法，最後連最基本的問題都答不出來：這個 agent 到底能碰哪個 repo？誰批准的？出事時怎麼立刻停掉？

NewCore 的重點是把「agent 本身」當成管理對象，而不是管理那把鑰匙。這個想法比較乾淨，因為它跟企業原本管理人的方式是同一套語言：誰擁有、能做什麼、什麼時候到期、怎麼撤。

實操上，我會要求每個 agent 都有明確 principal 名稱、owner、scope、expiry、revocation path。不要共享人類 token，不要讓五個 automation 共用一把池子裡的 key。更重要的是，這個身份要能出現在 log、access review、incident response 裡，不然等於沒管。

人類的 identity 系統本來就快撐不住了

NewCore 創辦人 Zohar Alon 說，15 或 20 年前做的 identity platform，面對 AI agent 的規模和複雜度會撐不住。我不覺得這是誇張話。那些系統原本是為了員工、外包、少量機器設計的，不是為了會自己發 request、會協作、會臨時要權限的軟體工作者。

Alon 還提到一個很刺耳但很真實的故事：他在 2023 年看過一家公司的 identity 預算，看到金額時以為客戶應該很滿意，結果客戶根本不爽。這種故事我反而信，因為它說明市場上很多工具是「大家忍著用」，不是「真的好用」。

這件事放到 agent 身上只會更糟。你如果連人員的 joiner-mover-leaver 流程都做得半吊子，agent 只會把問題放大；如果 access review 本來就是季度打勾，agent 會把它變成一個更快、更難追的安全洞。

所以我的判斷很簡單：不要等某個專門的 agent IAM 產品來救你。先把基本功補起來。owner metadata 補齊、stale account 清掉、approval 規則標準化、revocation 變成可量測。AI 不是創造身份問題，它只是讓老問題變貴。

• 先盤點你現有的所有 non-human principal。
• 標記哪些是人擁有、哪些是服務擁有、哪些是共享的。
• 把沒有 owner 或沒有 expiry 的直接列入清除清單。

把人和 agent 放在同一個 control plane 才像樣

NewCore 說它把 human 和 AI-agent identity 放進同一個系統管理。我覺得這才是重點。很多廠商現在只是在人類 identity stack 上補 agent 支援，短期也許夠用，但如果 agent 數量真的長起來，你不會想再維護一個旁支產品。

白話講，如果員工可以在同一個地方幫 agent 核准存取、查授權紀錄、做撤權，那整個組織就只需要一套心智模型。一份 audit trail，一條 revoke path。比起把 policy 切成「真人」跟「自動化東西」兩套，然後祈禱中間沒洞，這種做法至少像個正經系統。

我以前待過的組織就有這種破碎感：app secret 一套、cloud IAM 一套、內部 SSO 又一套。每切一刀，就多一個沒人真正負責的地方。事故來的時候，大家不是修問題，是先對帳。這就是 NewCore 想砍掉的摩擦。

實作上，我會要求單一真實來源。agent 要跟人一樣出現在同一個 directory、policy engine、audit trail。產品如果講不清楚這個 agent 是誰擁有、能碰什麼，我就不會買單。

Split-key 的重點不是炫技，是縮小爆炸半徑

“NewCore uses what it calls a ‘split-key’ architecture that divides critical identity credentials between the customer and the platform, an approach designed to eliminate a single point of compromise.”

翻譯一下就是：廠商不拿完整秘密。這點其實很務實。太多 identity 和 access 系統最後都變成一座大 vault，平常很方便，出事時很要命。

split-key 不像什麼華麗 crypto 表演，比較像是把操作上的 paranoia 做進系統裡。你就算打穿其中一邊，攻擊者也還拿不到全部。這種設計讓我比較安心，因為它看起來像真的有想過 enterprise security 的髒事，不只是 demo 好看。

但我還是會追問：如果 customer 端掛了怎麼辦？恢復流程是什麼？key 怎麼 rotate？會不會因為太麻煩，最後 admin 自己繞過？這些問題才是產品能不能落地的關鍵，不是架構圖畫得漂不漂亮。

實操上，我會建議把 approval、secret custody、enforcement 分開。能拆的 trust 就拆。不要讓單一 admin、單一 app、單一 vendor 可以完整 impersonate 一個 agent。然後把 recovery path 寫清楚，先寫再上線，不要等出事才補。

• 把 approval 跟 credential custody 分開。
• 每個 agent 都要有明確 revoke 路徑。
• 測試其中一邊離線時系統會怎樣。

agent 的授權流程一定要有人類介入

NewCore 的 mobile app 讓員工可以 grant、review、revoke AI agent 的 access。這看起來像小功能，但我其實最在意這個。自治系統的問題不只是它能做什麼，而是它會不會在沒人記得的情況下越跑越遠。

把 review 和 revoke 放進 mobile workflow，算是很務實的選擇。因為老實說，沒人想每次都去一個超大的 admin console 幫 agent 開新權限。大家要的是快，但又要留痕跡。

我看過很多團隊死在授權流程設計太爛：太麻煩，大家就開始亂按同意；太簡單，又等於沒有流程。流程如果很煩，最後只會被人繞過。流程如果太鬆，就只是裝飾。

實作上，我會把 agent approval 做成很像輕量 incident response 的步驟：誰在申請、要什麼、需要多久、拒絕會怎樣。撤權則要一鍵完成，不要變成 support ticket。

另外，UI 不是重點，state machine 才是。request、approve、expire、revoke、re-review 這五個狀態少一個都不行。少了任何一段，你不是在做治理，你是在做一個看起來很友善的 bypass。

工具整合才是這東西真正碰到開發者的地方

NewCore 說它的 “Agentic Skill” 套件能接 Anthropic Claude Code、OpenAI Codex、Cursor。這才是實際層。身份管理一旦碰到真實開發流程，就不再是抽象概念，而是直接踩到 repo、CI、cloud console、internal docs。

這很重要，因為開發者早就在最敏感的地方用這些工具了。若它們是透過 managed identity 而不是手動複製 credentials 來認證，你就會得到比較乾淨的 audit trail，也少掉一堆「這顆 token 到底誰貼到哪裡」的鬼故事。這些鬼故事，我真的看太多了。

我會把這當成 adoption wedge。沒人早上起床會興奮地想「我要去管 identity」。大家只會對 access friction 很有感。NewCore 如果能卡在 assistant 和 enterprise system 中間，還不把 workflow 弄得很煩，那它就有機會。

實作上，先挑一個高價值工具、一個窄權限集合開始。像是讓 coding agent 只能開 PR、讀 issue metadata，不准碰 production deploy。先觀察人類介入頻率，再慢慢放大範圍。

還有一件事要寫死：agent can act 跟 agent can decide 不是同一件事。很多團隊會把這兩件事混在一起，直到出事才發現自己早就把界線弄糊了。

市場已經動了，但買家還在摸索

NewCore 說自己目前少於 10 個客戶、超過 10 個 design partners，預計這個夏天開始收費。這代表這個類別還很早期。我反而覺得這樣正常；如果看起來太成熟，我才會懷疑。

更大的訊號是，公司已經開始把 agent 當員工看了。TechCrunch 文章裡提到 Goldman Sachs 在測 Devin 當新員工，McKinsey 也說有 25000 個 AI agents 跟 60000 名員工一起工作。每家公司是不是都準備好了，當然不是；但方向已經很明顯。

所以買家大概會分成三群：安全團隊想控風險、平台團隊想少點混亂、開發者只想 agent 不要一直要密碼。NewCore 得同時滿足這三群人，還不能把系統做成一個難維護的怪物。

實作上，我會直接問四個問題：這個 agent 誰擁有？它能碰什麼？授權什麼時候過期？我現在能不能立刻撤掉？如果答案要開會才講得清楚，那產品還沒準備好。

我自己的結論很直白：NewCore 真正在賣的不是 identity software，而是避免 AI agents 變成看不見的員工、拿著看不見的權限。這問題值得解，而且如果大家再拖，很多團隊會自己踩進去。

可抄的模板

# AI Agent Identity Policy Template

## 1) Agent record
- Agent name:
- Business owner:
- Technical owner:
- Purpose:
- Environment: dev / staging / prod
- Start date:
- Expiration date:
- Review cadence:

## 2) Identity model
- Each agent must have a unique identity.
- No shared credentials across agents.
- No human personal tokens for agent use.
- No long-lived secrets without expiry.

## 3) Access request
For every request, capture:
- Agent name
- Requested system
- Requested permissions
- Reason for access
- Time limit
- Approval owner
- Fallback if denied

## 4) Approval rules
- Low-risk access: technical owner approval
- Sensitive access: business owner + security review
- Production access: explicit approval every time
- Emergency access: time-boxed and logged

## 5) Credential handling
- Split approval from secret custody where possible.
- Rotate credentials on schedule.
- Revoke on owner change, incident, or expiry.
- Log every credential issuance and revocation.

## 6) Monitoring
Track:
- Active agents
- Granted permissions
- Last use time
- Failed access attempts
- Revoked identities
- Overdue reviews

## 7) Revocation checklist
When shutting an agent off:
- Disable identity
- Revoke tokens
- Remove group memberships
- Cancel scheduled jobs
- Verify downstream access is gone
- Record incident or change ticket

## 8) Developer workflow gate
Before a coding assistant can access enterprise systems:
- It must be registered as an agent.
- It must use managed identity.
- It must have a scoped permission set.
- It must be reviewable and revocable by humans.

## 9) Review questions
- Who owns this agent?
- What can it touch?
- What breaks if it is compromised?
- How fast can we revoke it?
- What evidence do we keep for audit?

## 10) Approval note
Approved by:
Date:
Scope:
Expiry:
Revocation owner:

這段是我把 NewCore 的概念翻成你可以直接貼進內部政策、security review、或產品需求文件的版本。不是它們的官方 spec，是我根據文章內容整理出的可用模板。

來源是這篇 TechCrunch：https://techcrunch.com/2026/06/15/ai-agents-are-becoming-employees-newcore-emerges-with-66m-to-give-them-identities/。文中的 funding、引述與產品主張來自 Jagmeet Singh；上面的拆解、流程化寫法和模板是我自己的整理。