最小權限
只提供完成任務所需的最小權限。
安全原則
以最小權限與清楚責任，建立可持續的信任基礎
必要知悉
資料是否可見取決於工作責任與必要性。
可追蹤性
重要操作與狀態變化保留可追蹤脈絡。
資料最小化
降低不必要的資料收集、顯示與處理。
能力狀態
把目前能力、設計原則與未來方向分開說清楚
狀態標籤避免將架構構想誤解為已部署功能。
身份識別
目前能力辨識使用者，讓後續角色與資料範圍判斷有明確起點。
角色權限控制（RBAC）
目前能力以申請人、招生管理者、系所人員、審查者與系統管理者等角色區分操作權限。
資料範圍控制
目前能力角色決定可以做什麼；資料範圍進一步限制可以對哪些資料執行。
個資遮罩
目前能力依角色與情境降低不必要的個人資料曝光。
操作紀錄
目前能力記錄人員、時間、操作、目標與結果等重要事件。
權限感知檢索
設計原則讓未來 RAG 檢索延續身份、角色與資料範圍邊界。
AdmissionsOS AI／RAG 層
未來整合以既有結構化招生流程、文件與權限脈絡支援後續 AI 整合。
身份識別
先知道使用者是誰，才有後續的授權判斷
身份是角色與資料範圍判斷的起點。本站不宣稱未經確認的 MFA、OIDC、SAML 或 SSO 支援。
已驗證身份角色指派政策脈絡
角色權限控制
角色決定可以執行哪些操作
AdmissionsOS 以不同招生與審查角色區分權限。實際權限配置應依學校流程與責任設計。
申請人權限組合 01 招生管理者權限組合 02 系所人員權限組合 03 審查者權限組合 04 系統管理者權限組合 05
RBAC + 資料範圍
可以做什麼，和可以對哪些資料做，是兩個不同問題
角色權限
＋我可以執行這項操作嗎？
審查者可以執行審閱與提交評分。
資料範圍
可以對哪些紀錄操作？
審查者僅能存取分派給其學程或任務範圍的案件。
角色＝審查者
學程甲 允許學程乙 拒絕
目前能力個資保護
敏感資料不應因為進入流程，就對每個角色完整可見
個資遮罩與最小必要存取的目標，是依工作情境降低不必要的資料曝光。AdmissionsOS 具備遮罩能力；AI 流程的範圍式檢索屬架構原則。
目前能力設計原則
完整資料姓名：申請人甲識別碼：A123456789電子郵件：applicant@example.com
政策 + 角色 + 資料範圍遮罩後畫面姓名：申請人甲識別碼：A12•••••••電子郵件：a••••••@example.com
稽核紀錄
重要操作應留下可被理解的事件脈絡
稽核紀錄可記錄人員、時間、操作、目標與結果。下方為概念示意資料，不代表真實使用者或正式保留期限。
活動紀錄示意資料
09:10
管理者更新招生方案招生方案 #001
09:18
審查者開啟報名案件報名案件 #001
09:23
審查者送出評分報名案件 #001
09:35
管理者變更錄取狀態報名案件 #001
資料治理
從收集到移除，每個階段都有不同責任
資料生命週期應由組織政策定義；本站不宣稱特定保存、刪除、備份、RTO 或 RPO 條件。
- 01收集
依流程目的收集必要資料。
- 02保存
在應用脈絡中維持資料結構與狀態。
- 03存取
依身份、角色與資料範圍控制存取。
- 04使用
將資料使用限制在核准的工作情境。
- 05追蹤
記錄重要操作與狀態事件。
- 06保留／移除
依組織正式政策設定保存與移除規則；本站不宣稱固定期限。
應用安全
從應用設計層建立基本安全邊界
以下是系統設計與工程關注點，不代表第三方驗證、正式認證或特定服務等級。
以證據為先的溝通 本站不宣稱 ISO 27001、SOC 2、CSA STAR、滲透測試週期、全年無休 SOC 或其他尚未提供證據的安全能力。
AI 安全邊界
AI 不應繞過應用程式原有的權限邊界
AI 可用的脈絡應由身份、角色與資料範圍決定。未被授權的資料不應因為 AI 查詢而變得可見。
01使用者
02身份
03角色／資料範圍
04授權資料
05AI／RAG
06回應與來源
以清楚建立信任
從角色、資料範圍與治理需求開始討論。
我們會清楚區分目前能力、設計原則與未來整合方向。