Oracle 19C中CURRENT_USER与SESSION_USER不一致的原因排查

我接手了一套生产环境Oracle系统的维护工作，原开发人员未做任何交接。搭建新测试环境时，发现生产系统存在无法解释且无法复现的异常行为：系统包含SYS_USER和APP_USER两个schema，服务以APP_USER身份连接，该用户仅被授予某表的SELECT权限，但却能成功执行该表的UPDATE操作。

在另一个存在相同异常的测试环境中，我在涉事表上创建触发器，记录UPDATE操作时的CURRENT_SCHEMA、CURRENT_USER和SESSION_USER，得到以下结果：

• SESSION_USER = APP_USER，符合预期
• CURRENT_SCHEMA = SYS_USER，经查是登录触发器执行ALTER SESSION SET CURRENT_SCHEMA = SYS_USER导致
• CURRENT_USER = SYS_USER，这是问题核心。已知Oracle通过CURRENT_USER评估权限，但找不到独立修改该值的方法，且10G后CURRENT_USER与SESSION_USER的差异已基本弃用，我们使用的是19C版本。

我需要找到AWS托管Oracle 19C中触发CURRENT_USER与SESSION_USER不一致的方法，并且怀疑无需SYS_USER密码即可实现（应用配置中没有该密码，测试环境修改SYS_USER密码后仍能正常运行）。

更新：
Jameson_uk的回复帮助理解了标题相关的问题，但现有证据仍指向一个令人困惑的场景：

• 环境A：应用无MYTABLE的UPDATE权限却能执行更新，触发器日志确认当前用户为APP_USER且无该权限，但手动以APP_USER身份执行同一条语句会被拒绝
• 环境B：必须授予APP_USER UPDATE权限才能执行成功，排除了通过存储过程执行的可能

我怀疑应用栈存在非常规操作，希望得到复现环境A场景的方法，以缩小排查范围。

触发器代码 #

create or replace trigger sys_user.mytable_updatelogger
  after update on sys_user.mytable
  for each row
declare
  v_update_privs varchar2(1000) = '';
begin
  for r in (select *
              from user_tab_privs
             where privilege = 'UPDATE'
               and grantee = user) loop
    v_update_privs := v_update_privs || r.table_name || '; ';
  end loop;
  insert into debuglog
    (log_msg, log_timestamp)
  values
    ('Update on MYTABLE:
Logged in user: ' || user || '
Assigned UPDATE privileges: ' || v_update_privs, sysdate);
end;

内容的提问来源于stack exchange，提问作者Uffe Poul Hansen