Multi-Layer Security Architecture
Complete Documentation of the V.E.T.S. Security System
This comprehensive guide explains the security and permission infrastructure that protects data and controls access throughout the V.E.T.S. Livestock Management System.
V.E.T.S. implements a sophisticated 6-layer permission system built on a foundation of Domain isolation (multi-tenant boundary). ALL layers must grant access for an operation to succeed.
Why This Complexity? Managing 6 interdependent security layers across thousands of users, animals, and documents is beyond human capacity to do consistently. This architecture is designed for AI-assisted permission management - where the system can evaluate all layers simultaneously, suggest optimal configurations, and catch edge cases humans would miss.
The Six Permission Layers
🛡 Defense in Depth
Permissions are evaluated in order. Every request must pass ALL applicable layers. This "defense in depth" approach ensures robust security - a failure at any layer blocks access.
Foundation: Domain Isolation (Layer 0)
Before the 6 layers even apply, users must be within the correct Domain. Domains provide multi-tenant isolation - the boundary that separates one organization's data from another.
Source: sfnc_System_GetDomain() | Scope: Entire tenant boundary
Domain Types: Organizational (clinics, ranches), Personal ($user@email.com), System accounts
Key Point: Domain isolation is the foundation everything else builds on. You cannot access data outside your domain regardless of other permissions.
Layers 1-3: Table, TeamDoc, TreeList
Layer 1: Table-Level Permissions
Source: sviw_System_MyPermissions | Grants: S (SELECT), I (INSERT), U (UPDATE), D (DELETE)
Who Grants: System administrators | Scope: Entire table
Note: Required but NOT sufficient - must also pass Layers 2-6
Layer 2: TeamDoc Permissions
Source: sviw_TeamDoc_MembersWithTDandName | Levels: Reader, Editor, Manager
Scope: Per-item (each Item/TreeList has its own TeamDoc)
Creator Rule: Item creator automatically gets Manager access
Layer 3: TreeList Group Permissions
Pattern: TreeList name → Group name (spaces → underscores)
Example: "Professional Services" → VETS_Professional_Services_Editor
Scope: All items within a TreeList category
Layers 4-6: Ownership, Row-Level, UI
Layer 4: Animal Ownership Permissions
Source: stbl_AnimalOwnership + User Groups
Logic: User must own the animal OR be in an authorized professional group (veterinarian, ranch hand, etc.)
Scope: Individual animals - the most granular permission level
Layer 5: Row-Level Permissions (Criteria-Based Filtering)
Source: stbl_System_TableRowsPermissions + stbl_Database_Objects
How It Works: Filters rows based on field value patterns using LIKE matching
Configuration: Define filtering fields in stbl_Database_Objects (CField1, CField2), set criteria patterns in TableRowsPermissions
Current Use: Personal data isolation (mailboxes, calendars), confidential data filtering. Infrastructure ready for expanded use cases.
Layer 6: UI-Level Security (HTML-in-SQL)
Methodology: HTML-in-SQL - Interface elements are conditionally rendered at database level
Impact: Unauthorized actions are never generated, not just hidden
Advantage: Security enforced at UI creation, eliminating entire attack surface categories
Innovation: Server-side UI generation with permission-aware rendering
Row-Level Security Deep Dive
How Criteria-Based Filtering Works
Row-level security uses pattern matching on designated fields to filter what users see. This is different from per-record permissions - it filters by field VALUE patterns.
Example 1: Personal Mailboxes
-- Configuration (stbl_Database_Objects):
Table: stbl_Mail_MailBoxes
CField1 = "Login" -- Filter on this field
-- Permission (stbl_System_TableRowsPermissions):
User: user@example.com
Criteria1 = "user@example.com" -- Show records matching this
-- Result: User sees ONLY their own mailbox
Example 2: Confidential Data Classification
-- Configuration:
Table: atbl_RiskMgmt_Risks
CField1 = "Confidential" -- Boolean/flag field
-- Managers: Criteria1 = "%" (wildcard = see all)
-- Staff: Criteria1 = "0" (see only non-confidential)
-- Result: Data classification based on field value
💡 When to Use Row-Level Security:
Personal/user-specific data (each user sees only their records), simple flag-based filtering (confidential vs. non-confidential), pattern matching on field values.
When NOT to use: Items, Animals, TeamDoc content - Layers 2-4 handle these better with more flexibility.
Implementation: Views generated by sstp_Database_CreateView automatically include criteria filtering. This infrastructure is ready for expanded multi-tenant scenarios.
Limitations: Can only filter on 2 fields (CField1, CField2), only LIKE pattern matching (no complex Boolean logic), requires view regeneration when configuration changes.
Real-World Scenarios
How the Layers Work Together
Dr. Smith (Veterinarian): ✅ [Full Access]
Domain ✔ → Table ✔ → TeamDoc ✔ → TreeList ✔ → Ownership ✔ → Row-Level ✔ → UI shows full SOAP notes
Jane (Vet Tech): ⚠ [Restricted Access]
Domain ✔ → Table ✔ → TeamDoc ✔ → TreeList ✘ → Stops here. Can VIEW records but simplified UI, no editing.
Sarah (Horse Owner): 👤 [Owner Access]
Domain ✔ → Table ✔ → TeamDoc N/A → TreeList N/A → Ownership ✔ (her horse) → Client-facing UI only
External Consultant: ❌ [Blocked at Domain]
Domain ✘ → Stops immediately. Different tenant = no data visibility regardless of other permissions.
Why AI-Managed Permissions?
Consider the complexity: 6 permission layers, each with different scopes, sources, and rules. Multiply by thousands of users, animals, and documents. Add temporal factors (custody transfers, temporary access). No human can consistently manage this correctly.
AI Permission Management enables: automatic permission optimization, smart access suggestions that respect all 6 layers, security audit and anomaly detection, bulk provisioning without missing edge cases.
Permission Layer Quick Reference
| Layer |
Name |
Source |
Scope |
| 0 |
Domain Isolation |
sfnc_System_GetDomain() |
Tenant boundary (foundation) |
| 1 |
Table-Level |
sviw_System_MyPermissions |
Entire table (SUID) |
| 2 |
TeamDoc |
sviw_TeamDoc_MembersWithTDandName |
Per-item (Reader/Editor/Manager) |
| 3 |
TreeList Groups |
TreeList → Group naming convention |
Category-wide |
| 4 |
Ownership |
stbl_AnimalOwnership + Groups |
Individual animals |
| 5 |
Row-Level |
stbl_System_TableRowsPermissions |
Field-based filtering |
| 6 |
UI-Level |
HTML-in-SQL generation |
Interface elements |
Remember: Layer 0 (Domain) is the foundation - you must be in the right domain before any other layer applies. Layers 1-6 are then evaluated in order. Access requires ALL applicable layers to pass.
Security Best Practices
✅ Do: Grant minimum necessary permissions, use TeamDoc for collaboration control, let AI suggest permission configurations, regularly review ActivityLog
❌ Don't: Grant blanket Layer 1 permissions, manually manage complex permission scenarios, mix professional groups inappropriately
The Future: AI-Managed Security
The 6-layer architecture is intentionally sophisticated. It provides defense in depth that no single point of failure can compromise. But this complexity also means humans cannot reliably manage it at scale.
AI-assisted permission management transforms this from a burden into an advantage: the system becomes self-auditing, self-optimizing, and consistently correct across all 6 layers simultaneously.
ℹ Current Status: V.E.T.S. has been operating securely in production for 15+ years. The multi-layer architecture provides robust protection while the AI integration layer enables scalable, consistent permission management.